Choosing a tech stack for an MVP is one of the most over-thought decisions in software. Founders agonise over frameworks as if the choice is permanent and existential. It usually isn’t. But a handful of decisions genuinely are hard to reverse — and those are the ones worth slowing down for.

Optimise for speed of iteration, not theoretical scale

Your MVP’s job is to help you learn whether you’re building the right thing. That means the most valuable property of your stack is how quickly you can change it. Boring, well-documented technologies your team already knows will almost always beat the exciting new framework you’d be learning on the job.

Pick the stack that lets you ship on Friday and change your mind on Monday.

The decisions that are actually hard to undo

Most choices are cheap to reverse. A few are expensive. Spend your deliberation budget here:

  • Your data model. Reshaping a database that’s full of production data is painful. Get the core entities and relationships right.
  • Your authentication and identity model. Migrating how users log in touches everything. Use a proven provider rather than rolling your own.
  • Anything that touches money. Payments, billing and ledgers deserve real care from the start.

A default stack we reach for

We deliberately keep a sensible default so we’re not re-litigating fundamentals on every project. It’s not the only right answer — it’s a strong starting point we deviate from only with a reason.

  1. A typed language end-to-end, so refactors are safe as the codebase grows.
  2. A managed database — we’d rather pay for reliability than operate it ourselves at this stage.
  3. A component-driven frontend with a design system from sprint one.
  4. Infrastructure as code, even for the MVP, so environments are reproducible.
Rule of thumb

If a technology choice can be changed in a week by one engineer, don’t spend more than an hour debating it. Save the deliberation for the decisions measured in months.

When to break your own rules

Sometimes the “exciting” choice is correct — when it directly serves the product’s core promise. If you’re building a realtime collaboration tool, the realtime layer isn’t a place to be boring. Spend novelty budget where it differentiates you, and be relentlessly conventional everywhere else.

The takeaway

The right MVP stack is the one your team can move fastest in, with extra care reserved for the few decisions that are genuinely costly to reverse. Everything else is a detail you can change once real users tell you what actually matters.