How to choose a tech stack for a startup

What tech stack should a startup use?

Use the stack your founding engineers are fastest in, provided it has a large hiring pool, a mature ecosystem and a managed hosting story. Novelty is a cost you pay every day and a benefit you collect almost never.

Which technical decisions are hard to reverse?

Roughly four: your data model, your identity and permissions boundary, your primary datastore's consistency guarantees, and any integration your customers can see. Everything else — CSS framework, hosting provider, even language for a new service — is comparatively cheap to change.

Should a startup use microservices?

Almost never at the start. A well-structured single deployable — a modular monolith — gives a small team faster iteration, simpler debugging and one place to look when something breaks.

How do you evaluate a new framework or vendor?

Score it against operability and exit cost before features. The question is not 'is this good' but 'what happens to us if this is abandoned, priced up 4x, or the wrong fit in eighteen months'.

Frequently asked questions

Is it bad to build a startup on a monolith?

No — it is usually the right call. Most companies that regret their architecture regret premature distribution far more than they regret a monolith they later split deliberately.

Should startups use serverless?

It is an excellent default for spiky, event-driven workloads and for teams without operations depth. Watch for cost at sustained high volume and for local development ergonomics.

How often should a startup rewrite its stack?

Rewrites should be rare and incremental. Strangle the old system component by component behind a stable interface rather than freezing features for a big-bang replacement.