The lion hunting the zebra

The lion hunting the zebra

0 views

Most indie devs and small teams massively over-optimise their tech stack and under-optimise their distribution, pricing, and positioning.

The result: beautiful codebases, almost no revenue.

The uncomfortable truth

If you are a technical founder, your advantage is speed of execution, not perfect architecture.

You win by:

  • Shipping fast, not shipping perfectly.
  • Talking to users weekly, not refactoring weekly.
  • Killing bad bets early, not “salvaging” them with rewrites.

Every week spent debating frameworks is a week you are not:

  • Closing a customer.
  • Improving activation.
  • Increasing LTV or lowering churn.

When your stack becomes a cage

Your stack becomes a liability the moment it starts dictating product decisions.

You know it’s happening when:

  • You choose features based on what is easy in your stack, not what users actually want.
  • You hesitate to test new directions because “it doesn’t fit the architecture”.
  • You are afraid to throw away code because it’s “too elegant to kill”.

That is not engineering discipline. That is sunk cost fallacy with prettier abstractions.

A better default for builders

For early-stage products, a simple rule works surprisingly well:

Optimise for reversible decisions.

In practice:

  • Pick boring, proven tools.
  • Err on the side of fewer services, fewer repos, fewer moving parts.
  • Keep everything scriptable so you can automate after you have something people use.

You want a stack that makes it trivial to:

  • Add a field.
  • Launch a new landing page.
  • Ship a scrappy internal tool in a day, not a week.

If a decision is hard to reverse in month one, it is probably the wrong decision.

Execution beats architecture (early on)

Architecture starts to matter after you have:

  • Clear pull from users.
  • A repeatable way to acquire them.
  • A reason to believe this thing should exist at scale.

Before that, optimising the system is premature.

Instead, optimise:

  • Feedback loops (how fast do you learn?).
  • Shipping loops (how fast do you release?).
  • Revenue loops (how fast can you test pricing and packaging?).

Your code only matters to the extent it accelerates those loops.

A practical operating system

If you want a simple operating system for your next product:

  1. Default to one codebase.
    Monorepo, single app, minimal services. Add complexity only when there is pain you can clearly name.
  2. Decide tech choices on constraints, not taste.
    Hosting, compliance, latency, and team skills are real constraints. Aesthetic preferences are hobbies.
  3. Measure output, not effort.
    Track shipped features, closed deals, onboarding time, MRR. Velocity is a feature.
  4. Timebox “engineering for fun”.
    Want to play with a new database or message bus? Give it a budget: one evening, one weekend. Not your entire runway.

The mindset shift

As a technical founder, the real unlock is accepting that your stack is a means, not an identity.

You are not “a Next.js founder” or “a Rails founder”. You are a problem solver with a toolbelt.

Once that clicks, tech decisions become calm, boring, and fast. And that is exactly what you want, because the interesting problems are all outside the codebase.

Ship the thing.
Talk to people.
Let the stack be invisible.