Choose an MVP tech stack for the next 18 months, not for the scale you hope to reach. That means a mainstream web framework your developers already know, a relational database, managed cloud hosting, hosted services for payments, email and authentication, and a cross-platform framework if you need a mobile app. The stack decision matters far less than founders fear and far less than the data model, which is the one part that is genuinely hard to change. A boring stack with good structure beats a modern stack with bad structure every time.
Founders worry about the tech stack more than almost any other MVP decision, and it is one of the least consequential. Most products succeed or fail on whether users want them, not on which framework rendered the screen. That said, a few stack choices are hard to reverse, and a few common mistakes cost real money. This post explains what actually matters, gives a sensible default by product type, and tells you what to ask the team proposing a stack. If the terms are unfamiliar, what is a tech stack defines them.
What is the one rule?
Choose for the next 18 months. An MVP needs to ship in weeks, change weekly for a year, and be maintainable by whoever is around in month twelve. It does not need to handle a million users, because if it reaches a million users you will have the money and the evidence to change whatever needs changing. Every stack decision should be tested against that: does this help us ship and change quickly for the next year and a half? Anything chosen for scale, for a future hire's preference, or for how it sounds in a pitch fails the test.
What is the default stack by product type?
| Product type | Front end | Back end and data | Notes |
|---|---|---|---|
| Web SaaS or B2B tool | A mainstream web framework with server-side rendering | A mainstream backend framework, a relational database, managed hosting | The most common MVP shape. Boring is correct. |
| Consumer mobile app | A cross-platform mobile framework, one codebase for iOS and Android | Same backend as above, plus push notifications | Native only if the app depends on hardware features. See native vs cross-platform. |
| Marketplace | Web first, often with a mobile app for one side later | Relational database, hosted payments with split payouts, search service when listings grow | Two user types and payments make this the longest MVP build. |
| AI-assisted product | As above by platform | As above, plus a hosted model behind a boundary and a job queue | Keep the model swappable. See building an AI MVP. |
| Content or booking platform | Web, with attention to search engines | Relational database, a content management layer if staff edit often | Server-side rendering matters for search visibility. |
Across all of these: hosted authentication, hosted payments, a transactional email service, managed cloud hosting with automated backups, error tracking and analytics from the first deploy. None of those should be built. All of them should be present.
Which choices are hard to reverse?
- The data model. How accounts, users and the core records relate. Get the ownership structure right, meaning which record belongs to which organisation, and almost everything else can change. Get it wrong and every feature fights it. Our post on what a database is explains why.
- The database type. Relational is the right default for almost every product. A document or graph database chosen for novelty is a common and expensive regret.
- Native versus cross-platform for mobile. Switching means rewriting the app.
- The no-code decision. Products built on no-code platforms are rebuilt, not migrated, when they outgrow the platform. Right for some MVPs, as no-code vs custom explains, but a one-way door.
Everything else, from the front-end framework to the hosting provider to the programming language, is changeable at a cost proportional to the size of the product, and that cost is lowest when the product is an MVP.
What are the common mistakes?
- Choosing for scale. Microservices, multiple databases, event streaming, container orchestration. Each is right at a scale an MVP will not see, and each adds weeks and operational burden now.
- Choosing the new thing. A framework released last year has fewer developers who know it, fewer libraries, more breaking changes and a real chance of being abandoned. Pick what has been mainstream for five years.
- Choosing what one developer likes. A stack only the current developer knows is a hiring problem the day they leave.
- Building what can be bought. Authentication, payments, email, file storage, search. Each has a hosted service that is better than what you will build in the time available.
- Three platforms at once. Web, iOS and Android in the first release triples the front-end work. One platform first, as mobile app or web platform argues.
What should you ask the team proposing a stack?
- How many products have you shipped on this exact stack?
- How many developers in the market know it? If we needed to replace you, how hard would hiring be?
- Which parts are hosted services and which are built? Why build those?
- What in this stack is chosen for scale we do not have yet?
- Show me the data model before the framework.
A good team answers these in minutes and the answers are boring. A team that leads with the newest framework name or with a diagram of services for a product with no users is proposing their preferences, not your product. Questions to ask before hiring an app development company has the wider list.
The MVP stack rule
- Mainstream framework, relational database, managed hosting.
- Buy authentication, payments, email, storage, search.
- One platform. Cross-platform if mobile.
- Spend the thinking on the data model, not the framework.
- Nothing chosen for scale you do not have.
How 7L chooses stacks
We have a small number of stacks we build most products on, chosen because they are mainstream, well-supported and known by every engineer in our New York, London and Athens teams. The stack conversation in discovery is short, and the data model conversation is long, which is the right way round. We say so when a founder asks for something fashionable, and we build it anyway if they insist, but we have the conversation first. If you have been proposed a stack and want a second opinion, send us the proposal.
Frequently asked questions
Does the tech stack affect MVP cost?
Less than founders expect. A mainstream stack with hosted services is the cheapest to build and run. An unusual stack costs more because fewer people know it, and a stack chosen for scale costs more because of the infrastructure it demands. The product scope drives cost far more than the stack.
Will investors care about the stack?
Rarely at seed stage, as long as it is mainstream and the code is owned and documented. They care about whether the product can keep shipping, which is a question about the team and the structure, not the framework. Our post on what investors want to see in your tech before seed covers what they do check.
Should an MVP use serverless or containers?
Either works. Managed hosting that deploys from your code repository with minimal configuration is the right level for an MVP. Container orchestration is scale infrastructure and waits until the product needs it.
Can the stack be changed later without a rebuild?
Most of it, yes. Front-end frameworks, hosting and individual services can be swapped piece by piece. The data model and the mobile platform decision are the hard ones, which is why they deserve the most thought at the start. See our post on rebuilding versus building on an MVP.
Is it a problem if my agency uses a stack I have never heard of?
Not if it is mainstream among developers, which you can check by searching job listings for it. It is a problem if it is obscure, if only that agency uses it, or if the agency cannot explain in plain terms why it was chosen over the common alternative.