How I choose the tech stack for a client MVP
The most common mistake I see founders make when starting a new product is treating the tech stack as an identity statement. They want to use the trendy framework, the cutting-edge database, the thing they read about on Hacker News last week.
That's almost always the wrong move. Here's how I actually think about it.
The only question that matters
Before I touch a single line of code, I ask one question: what does this product need to do reliably on launch day?
Not in year two. Not "what if we get a million users". On launch day, with real users, under real conditions.
Most MVPs need to do a handful of things well:
- Authenticate users
- Read and write data
- Show that data in a UI
- Maybe send an email or trigger a webhook
That's a solved problem. The stack almost doesn't matter — as long as it doesn't get in your way.
The framework I use
I evaluate every project against three axes:
1. Time to first working feature How fast can I go from empty repo to something a user can actually click? This eliminates exotic choices immediately. If I'm spending two days configuring the build pipeline, the stack has already failed.
2. Operational simplicity How hard is this to deploy, monitor, and debug at 2am when something breaks? I've seen MVPs collapse under their own infrastructure. Kubernetes is not an MVP tool.
3. Hire-ability If the product succeeds and the client needs to bring in a second developer, how easy is it to find someone? Obscure stacks create hiring cliffs that can kill a company.
What I default to and why
For 90% of client projects I build with Next.js + Node.js + PostgreSQL + Vercel.
Not because it's the best possible combination in theory. Because:
- Next.js handles routing, SSR, API routes, and image optimisation out of the box — that's weeks of setup I don't have to do
- PostgreSQL is the most battle-tested relational database in existence; it will outlive every NoSQL trend
- Vercel makes deployment a git push; zero DevOps overhead on an MVP budget
- Every developer on earth knows this stack; hiring is never a problem
The 10% where I deviate: real-time features heavy enough to warrant a dedicated WebSocket server, desktop apps (Java/JavaFX), or clients with existing infrastructure I need to integrate with.
The conversation I always have
When a client asks "can we use X instead?", I ask them: why?
If the answer is "because I've heard it's better", that's not a reason. Better at what? For whom? At what stage?
If the answer is "because our team already knows it", that's a great reason. Ship fast with what you know.
If the answer is "because we'll need to handle 10 million requests per day", I ask them how many users they have today. Usually zero. We'll cross that bridge if we ever get to it — and we can migrate then, with real data telling us what to optimise.
The real cost of a bad stack choice
The stack you pick in week one compounds. Every developer you hire has to learn it. Every bug is harder to Google. Every library you want might not exist for it.
I've inherited projects built on frameworks chosen because they were fashionable. The code works fine. The team hates it. Nobody wants to touch it. That's a real cost — measured in slow features, high turnover, and unhappy founders.
Pick boring technology. Build interesting products.
That's the rule I follow on every project, and it's the one I'd give to any founder starting from scratch.