Choosing a stack for an MVP you will actually keep

Most founders ask the stack question the wrong way round. They ask what is fastest, newest or most scalable, when the question that matters is: what will we still be happy to maintain in three years, with the team we can realistically hire? An MVP is not a throwaway prototype. If it works, it becomes the product — and every shortcut in week one becomes a tax you pay every week after.

Here is the framework we use with clients before a single line of code is written.

1. Start from the problem, not the tools

A booking platform, a marketplace and an internal dashboard have very different shapes. Write down the three or four things the product must do on day one, and the data each of them touches. That list tells you more about the right stack than any comparison chart.

• Is it mostly content and forms? A modern web framework with a managed database is plenty.
• Does it handle money? Pick tools with mature payment libraries and clear audit trails.
• Is it real-time — chat, live tracking, collaborative editing? Plan for it from the start; bolting it on later is painful.
• Will most users be on phones? Decide early whether you need a native app or whether a fast, installable web app is enough.

2. Choose boring technology on purpose

Boring does not mean old. It means well understood: widely used, well documented, with answers to most problems already written down somewhere. For most web products today that means TypeScript, React with a framework such as Next.js, and a mainstream database like PostgreSQL or MongoDB on a managed host.

The benefit is not technical elegance. It is that when something breaks at 2am, the fix is a search away, and when you need a second developer, you can hire one in weeks rather than months. Every unusual choice in your stack shrinks the pool of people who can work on it.

Spend your innovation budget on the product, not the plumbing. Customers never see your database — they only see whether the thing works.

3. Make hiring part of the decision

If you are a non-technical founder, the stack is also a staffing decision. Ask three questions of any proposed technology: how many developers in your market know it, what do they cost, and could a new developer understand the codebase in their first week? A stack your agency loves but nobody else can work on quietly locks you in.

This is why we document every build and keep it on mainstream tools. If you ever want to bring development in-house or move to another team, you should be able to — and knowing that keeps everyone honest.

4. Buy what is not your business

Authentication, payments, email delivery, file storage, search and analytics are solved problems. Managed services handle them better than a week of custom code can, and they cost very little at MVP scale. Building them yourself is the most common way first versions run late.

• Payments: a mainstream gateway available in your market, rather than a custom integration with a bank.
• Email: a transactional email provider, so password resets and receipts actually arrive.
• Content: a headless CMS, so your team can edit pages without a developer.
• Hosting: a managed platform that deploys on every push, rather than a server someone has to babysit.

The rule of thumb: build what makes your product different, and rent everything else. You can always replace a service later, once you know exactly what you need from it.

5. Design for the next three years, not the next ten

Founders often worry about scale they do not have yet. A well-built application on a mainstream stack will comfortably handle your first tens of thousands of users; by the time it cannot, you will have revenue, data about real usage, and a much better idea of what to optimise. Microservices, Kubernetes and multi-region databases solve problems you should be happy to have later.

What you should invest in early is the boring discipline that makes change cheap: a clear folder structure, typed code, automated deploys, error monitoring and a handful of tests around the parts that handle money or personal data.

A quick checklist before you commit

1. Can you explain why each major tool was chosen, in one sentence?
2. Could you hire a developer for this stack in your market within a month?
3. Are authentication, payments and email handled by proven services?
4. Does every push deploy automatically, with a way to roll back?
5. Is there error monitoring, so you hear about bugs before customers tell you?
6. Is the code yours — in your repository, under your account?

If the answer to all six is yes, your stack is good enough — and good enough, shipped this quarter, beats perfect next year. If you would like a second opinion on a stack or a proposal you have been given, send it to us; we are happy to give an honest read.