Choosing a tech stack for a startup MVP

Sort decisions by how hard they are to reverse

Not all technical choices carry the same weight, and treating them as if they do is why stack debates consume weeks. A useful first move is to sort every decision into one of two piles.

Reversible: your CSS approach, your component library, your hosting provider, most of your third-party services, and — more often than people expect — your frontend framework. Changing these later is annoying, not existential.

Expensive to reverse: your data model, your primary database, your authentication and identity model, and the boundaries between your services. These get woven through everything else. Spend your thinking here.

Most founders do the opposite: two weeks on the frontend framework, an afternoon on the schema.

Boring technology has a real advantage

An early-stage product has no traffic, no legacy, and no unusual constraints. What it has is a small team and a deadline. That combination favours technology with abundant documentation, obvious answers to common questions, and a large hiring pool.

PostgreSQL is a good default for almost every startup: relational when you need it, perfectly capable with JSON when you do not, and understood by every engineer you will ever hire. React and TypeScript on the frontend. Node, Python, or Go on the backend — chosen mostly by what your team already knows.

The exciting choice costs you in a way that is easy to miss: every hour spent debugging an unfamiliar runtime is an hour not spent on the product, and every unusual dependency narrows the pool of people who can take over later.

Choose what your team can already run

The best stack for your MVP is usually the one your team is fluent in. A senior engineer shipping in a familiar framework will outrun a stronger framework used badly, every single time. Novelty is a cost paid in weeks you do not have.

This applies to infrastructure too. If nobody on the team has run Kubernetes in production, an MVP is not the place to learn. A managed platform costs more per month and less per week.

Native or cross-platform, if you are shipping mobile

For most early products, cross-platform — React Native, or Flutter — is the right call. One codebase, one team, both stores. You drop to native modules where you genuinely need to, which is less often than the debate suggests.

Go native when the product is the platform integration: heavy camera or sensor work, complex background processing, tight OS-level features, or performance characteristics that are the actual selling point. If you cannot name the specific capability driving the decision, cross-platform will serve you better.

And remember the prior question: for an MVP you usually only need one platform at all. Pick where your users already are.

Buy the parts that are not your product

Authentication, payments, email delivery, error tracking, analytics, file storage. None of these differentiate you, all of them are deceptively deep, and each has a mature service that costs less per month than a day of engineering time.

The one caution: keep the integration behind a thin boundary of your own code. Not an elaborate abstraction layer — just enough that swapping the provider later touches a handful of files rather than two hundred.

Spend your real effort on the data model

If you take one thing from this article: the schema is the decision that outlives everything else. Your framework can be replaced in a quarter. A data model that got the core relationships wrong will distort every feature you build on top of it, and it will still be doing so three years later.

Sketch the entities and their relationships before you write code. Ask what happens when a user belongs to two organisations, when a record needs history, when something gets deleted that other things point at. You will not get it all right — but the errors you avoid here are the expensive ones.

What we recommend by default

• Database: PostgreSQL, until you have a specific reason otherwise
• Backend: Node.js, Python, or Go — whichever your team knows best
• Web: React with TypeScript; Next.js if you need server rendering or SEO
• Mobile: React Native, dropping to native modules where required
• Infrastructure: a managed platform first; move to raw cloud when the bill or the constraints justify it
• Bought, not built: auth, payments, email, error tracking, analytics

None of this is exotic, and that is the point. The interesting part of your startup should be the product, not the infrastructure underneath it.

If you would like a second opinion before committing to an architecture, talk to us — architecture review is something we do on its own, not only as part of a build.