How do you choose a tech stack for a startup?

Choose the stack your team already knows well enough to ship fast, that keeps your architecture reversible, and that doesn't burn months on infrastructure before you've validated anything. The right stack is almost always the boring, proven one your best engineer knows cold — not the newest framework on Hacker News.

Speed to first real user beats technical purity

The only thing a tech stack decision needs to optimize for in the first six months is: how quickly can you get something in front of real users? Every week you spend configuring a microservices architecture or debating ORM choices is a week your mental model of the customer is getting staler. The stack that lets your team move fastest toward a working product — even an ugly one — is the correct stack for now.

Paul Graham's point about doing things that don't scale applies directly here. Early-stage engineering should be oriented around learning, not elegance. A monolith you can deploy in a day beats a distributed system that takes three weeks to instrument and debug. You can refactor later; you cannot un-burn the time you spent on premature architecture.

The practical implication: take stock of what your founding team has shipped before under production pressure. The language and framework where you've already debugged the weird edge cases, already know the ecosystem's sharp edges, already have mental models for performance — that's your stack. Picking something new because it's exciting is a tax on your most valuable early resource, which is focused attention on customers.

Treat your early architecture as a hypothesis, not a commitment

One of the most damaging myths in early startup engineering is that your initial architecture will scale to millions of users, so you'd better design for it now. This is almost always wrong, and acting on it is expensive. The companies that scaled successfully almost universally rewrote substantial parts of their infrastructure once they actually understood their load patterns — and that's fine. What matters is that you designed your early system to be replaceable.

The key principle here is reversibility. Choose technologies where the failure mode is 'we'll have to rewrite this module in eighteen months' rather than 'we've painted ourselves into a corner and can't onboard the senior engineer we just hired.' A well-understood relational database, a mainstream web framework, and a single deployment target keeps your options open. Exotic choices — custom databases, novel languages, bleeding-edge infrastructure primitives — introduce lock-in and narrow your hiring pool at exactly the moment you need flexibility.

Garry Tan's engineering review thinking distinguishes between 'lakes' (completable, bounded work) and 'oceans' (multi-quarter rewrites and migrations). When evaluating a stack choice, ask which category the inevitable future migration falls into. Picking a stack where future changes are lakes is a better decision than picking one where every evolution becomes an ocean.

Hiring surface area is a real constraint

Your tech stack is also a hiring funnel. Whatever you build on determines who can contribute, how long onboarding takes, and how many people you're competing against for talent. A startup that chooses an obscure systems language for a web product isn't just making a technical decision — it's dramatically narrowing the pool of engineers who can be productive in week one, and signaling to candidates who value fast iteration that they might be in for a rough time.

This doesn't mean you should always choose the most mainstream option. If your product has a genuine technical requirement — real-time systems, computational biology, embedded hardware — then the right specialized tool is exactly right. But make sure the constraint is real and customer-facing, not aesthetic. The test is: does this technology choice directly improve something a user will notice, or does it mainly make the engineering team feel sophisticated?

For most B2B and consumer web products, the practical answer is some combination of TypeScript or Python on the backend, a mainstream relational database, and a deployment target that has good managed services. These choices won't impress anyone at a conference, but they let you hire from a large pool, find answers to problems quickly, and stay focused on what actually matters: building something people want.

When to actually revisit your stack

The right time to reconsider your stack is when a specific, measurable user-facing problem can only be solved by changing it — not before. Latency that's causing churn, a data model that makes a required feature structurally impossible, a language runtime that can't support concurrency at your actual scale: these are legitimate reasons. 'Our engineers think this would be cleaner in a different language' is not.

When you do face a real architectural decision, treat it with the same rigor you'd apply to a product decision. Name the actual problem. Define what success looks like. Estimate the cost in engineer-weeks and the risk to in-flight features. Compare two or three options with honest tradeoffs rather than defaulting to whatever is currently popular. The goal is to make a decision you can explain to a new hire in five minutes, not to build a showcase of technical ambition.

Finally, recognize that stack decisions compound. Each choice you make constrains the next one. A team that makes conservative, team-fluent choices early tends to accumulate technical debt that's manageable — incremental, module-by-module refactors they can do while shipping features. A team that front-loads exotic choices tends to accumulate technical debt that's structural — the kind that requires stopping feature work entirely to address. Boring early, ambitious later is almost always the right order.

“They want so much to seem big that they imitate even the flaws of big companies.”

— Paul Graham, source

The one thing to do

Pick the stack your best engineer has already shipped production code in, keep the architecture reversible, and don't change it until a specific user-facing problem forces you to.

Frequently asked questions

Should a non-technical founder have opinions on the tech stack?

Yes, on the constraints that matter to the business: time to ship, hiring pool, and whether the architecture can evolve. You don't need to choose the framework, but you should push back on choices that slow hiring or create irreversible lock-in before product-market fit.

Is it a mistake to use a newer technology like a cutting-edge framework or database?

Only if novelty is the main reason. If a newer tool genuinely solves a real technical problem your product has and your team has hands-on experience with it, it can be the right call. If you're choosing it because it's exciting or to attract engineers, that's a trap — those engineers will get bored and leave anyway once the novelty fades.

How do you handle it when co-founders disagree on the stack?

Time-box the decision to one week, pick the option your most experienced engineer has shipped production code in before, and document the reasoning. Disagreements that drag on for weeks are more damaging than a suboptimal stack choice — the cost of delay almost always exceeds the cost of picking second-best.

At what stage should you invest in infrastructure and DevOps tooling?

When a specific gap is causing meaningful engineering slowdown or customer-facing incidents, not on a schedule. Many early teams over-invest in CI/CD pipelines and observability before they have enough traffic or team size for those investments to pay off. Start with managed services and add complexity only when a real problem demands it.

Sources

More playbook answers · Growth Prophet home