Stop Reading Business Books and Start Writing Code

Business books are a procrastination trap. Stop reading about 'product-market fit' and start defining your database schema. That is where the real business lives.

I have a confession. My bookshelf looks impressive. It is stacked with titles like Zero to One, The Lean Startup, Atomic Habits, and pretty much every other "bible" of the tech entrepreneurship world. For a long time, looking at that shelf gave me a sense of security. It made me feel like I was doing the work. I was consuming knowledge. I was preparing.

But here is the brutal truth.

Those books didn't build my SaaS. They didn't help me debug a race condition in my database. And they certainly didn't configure my AWS VPC peering connections. While I was busy highlighting profound quotes about "product-market fit," other developers were shipping junk code, breaking things, fixing them, and actually getting customers.

There is a massive difference between feeling like a founder and being a builder. If you are stuck in the loop of reading about business strategy while your GitHub contribution graph looks like a barren wasteland, you are procrastinating. You are hiding.

It is time to put the books down. It is time to open VS Code.

The Illusion of Competence

Reading is comfortable. It is passive. When you read a book about how Instagram scaled to a billion users, you get a hit of dopamine. You borrow their success. You nod along and think, "Yes, I would definitely make that architectural decision too." It feels safe because the outcome in the book is already written.

Coding is the opposite. Coding is hostile. It exposes your stupidity immediately. You write a function, you run it, and it fails. The compiler doesn't care about your vision. The runtime doesn't care about your "Why." It only cares about syntax, logic, and state management.

When I shifted from churning out WordPress sites to building proper web applications with Next.js and Supabase, I hit this wall hard. I knew the theory of SaaS. I knew I needed recurring revenue. But I didn't know how to handle webhooks from Stripe properly without creating duplicate records.

Business books sell you the dream of the destination. Code forces you to walk through the mud.

Your Database Schema IS Your Business Plan

I stopped writing business plans years ago. They are fiction. They are guesses wrapped in fancy formatting.

If you want to know if a business idea is viable, try to design the database schema. Seriously. Open up a draw.io tab or just grab a piece of paper. If you cannot map out the relationship between your users, their subscriptions, and the core value unit of your application, you don't have a business. You have a daydream.

Let's look at this pragmatically. Say you want to build a project management tool for indie hackers. A business book tells you to define your "unique value proposition." Cool. Useless.

Code tells you to define your tables. This forces you to make actual decisions about how the product works.

create table projects (
  id uuid default gen_random_uuid() primary key,
  user_id uuid references auth.users not null,
  name text not null,
  status text check (status in ('active', 'archived')) default 'active',
  created_at timestamp with time zone default timezone('utc'::text, now())
);

create table tasks (
  id uuid default gen_random_uuid() primary key,
  project_id uuid references projects(id) on delete cascade,
  title text not null,
  is_completed boolean default false
);

By writing this simple SQL (or defining it in your ORM), you have done more to validate your product than a week of market research. You've decided that a task belongs to a project. You've decided that if a project is deleted, the tasks die with it (on delete cascade). You've defined the data structure.

This is the reality of engineering. The architecture is the strategy. If your data model is flawed, your business logic will be a nightmare, and no amount of marketing genius will fix a platform that is fundamentally broken.

The Stack is the Leverage

I used to be a WordPress guy. I still love WordPress for what it is. But in that world, you solve problems by finding the right plugin. You are an integrator, not an architect.

Moving to the modern stack - specifically Next.js, Tailwind, and Supabase - changed my brain chemistry. It gave me leverage. Speed is the only advantage an indie hacker has against the big guys. You cannot out-spend them. You have to out-ship them.

This is why I get annoyed when people spend weeks debating tech stacks on Twitter. "Should I use HTMX or React?" "Is Vercel too expensive?"

Just pick the stack that lets you move fast. For me, that is the T3 stack or a variation of it.

Next.js: Full-stack framework. SEO is solved. Routing is solved.
Tailwind + Shadcn UI: I don't have a designer. I don't want to think about border-radius. I just want it to look clean. Shadcn is a cheat code for this. copy-paste, done.
Supabase: It's Postgres wrapped in a nice DX. Auth is handled. Realtime is handled.

Here is what actual progress looks like. Not reading a chapter on "User Retention," but implementing a row-level security policy so users can't see each other's data.

// In Supabase, this is how you secure your business.
// No book teaches you the gut-check of pushing this to prod.

create policy "Users can only see their own projects"
on projects for select
using ( auth.uid() = user_id );

That creates a multi-tenant SaaS. That one line of code enables the business model. You can charge companies for seats now because the data is segregated. That is value.

The Cloud Trap: Don't Over-Engineer

I'm doing my Masters in Cloud Computing right now. I spend my days looking at AWS architectures, Azure resource groups, and Kubernetes clusters. It is fascinating stuff.

But here is the danger. As you get better at engineering, the temptation to over-engineer explodes.

You read a book or a whitepaper on microservices and suddenly you think your To-Do app needs to be broken down into six different lambda functions communicating via EventBridge.

Stop it.

I see developers spending three weeks setting up a Terraform pipeline for a project that has zero users. That is procrastination disguised as engineering rigor. It is the same as reading business books, just with a different flavor.

If you are an indie hacker or building an MVP, you do not need Kubernetes. You do not need a multi-region active-active database setup. You need a monolith that works.

Deploy to Vercel. Spin up a managed Postgres instance. Use a simple cron job.

When I build now, I force myself to be lazy. I ask: "What is the absolute minimum infrastructure required to make this run?"

Here is an example of a simple API route in Next.js. It does the job. It scales far further than you think.

import { createClient } from '@/utils/supabase/server';
import { NextResponse } from 'next/server';

export async function POST(request) {
  const supabase = createClient();
  const { data: { user } } = await supabase.auth.getUser();

  if (!user) {
    return NextResponse.json({ error: 'Unauthorized' }, { status: 401 });
  }

  const body = await request.json();

  // Business logic here. Straight to the point.
  const { data, error } = await supabase
    .from('subscriptions')
    .insert({ user_id: user.id, plan: body.plan })
    .select();

  if (error) {
    return NextResponse.json({ error: error.message }, { status: 500 });
  }

  return NextResponse.json(data);
}

This code handles authentication, validation, database insertion, and error handling. It's boring. It's simple. And it's shippable.

Fail in the IDE, Not in Your Head

The biggest problem with the "reading mode" is that it simulates failure without the consequences. You read about a startup crashing and burning, and you think, "I'll avoid that mistake."

But you won't learn until you feel the panic of a production bug.

I remember pushing a migration that locked a table in a live environment. The site hung. I was sweating. No book prepared me for the adrenaline spike of needing to SSH into a server (or use the Azure CLI) to kill a process.

That experience taught me more about database locking and transaction isolation levels than any textbook ever could.

You need to break things. You need to write bad code so you can recognize good code. You need to deploy a UI that looks terrible on mobile so you stop ignoring responsive design.

This is why I push for "Indie Hacking" as a mindset even if you work a 9-to-5. It's about ownership. When you build your own thing, there is no one else to blame. If the code sucks, it's on you. If the server crashes, it's on you.

The "Just In Time" Learning Model

I am not saying you should never learn theory. I am doing a Master's degree, after all. I value academic depth. But the order of operations matters.

Build first. Read second.

Encounter a problem you can't solve? Then read the documentation. Then read the book on distributed systems. Then read the article on React rendering patterns.

This is "Just In Time" (JIT) learning. It sticks because you have a context for the information. You aren't memorizing facts; you are hunting for a solution to a specific pain point you are feeling right now.

If you read a book on AWS IAM policies without ever having set up a role that failed to access an S3 bucket, the information will slide right off your brain. But if you've spent three hours debugging an "Access Denied" error, that documentation becomes gold. You will remember it forever.

Building is the Ultimate Networking

Business books love to talk about networking. "Build your network!" they scream.

Do you know the best way to network? Build cool shit.

When I share a screenshot of a dashboard I built with Shadcn and Recharts, or a snippet of code optimizing a Supabase query, I get engagement from other engineers. I get DMs. I get opportunities.

People respect output. They respect code. They do not respect a list of books you claim to have read.

When you share your journey of building - the actual code, the tech stack choices, the cloud architecture diagrams - you attract high-quality people. You attract fellow builders. That is the network you want. Not the people exchanging business cards at a conference talking about "synergy."

The Challenge

So here is my challenge to you.

If you have a business book on your nightstand that you haven't finished, put it away. Don't finish it.

Take the next 10 hours you would have spent reading and pour it into a project. It doesn't have to be the next Facebook. It can be a simple SaaS wrapper around the OpenAI API. It can be a tool to organize your bookmarks.

Initialize the repo.
Set up the database.
Build the auth.
Ship the first feature.

Get it on the internet. Get a URL. That URL is worth more than a library of business theory.

I am still learning this myself. Every day I have to fight the urge to go down a rabbit hole of "research" instead of doing the work. But I know that when I look back at my career, I won't be proud of the books I read. I'll be proud of the systems I built, the code I shipped, and the problems I solved.

Stop reading. Start coding. Let's get to work.