Founders often ask me which architecture they should choose for their MVP: microservices or a monolith, SQL or NoSQL, serverless or containers. It's a reasonable question, but it usually comes too early. The more useful question is: what decisions will be expensive to change later, and which ones won't?
An MVP exists to find out whether people want what you're building. Your architecture should help you learn that quickly — without creating problems you'll pay for if the answer turns out to be yes.
Start with a well-structured monolith
For almost every early-stage SaaS product, a single application with a clear internal structure is the right starting point. One codebase, one deployment, one database.
Microservices solve problems that come with scale and large teams: independent deployments, separate scaling, team autonomy. At the MVP stage you have none of those problems, and you'd be paying the full cost of distributed systems — network failures, data consistency, more infrastructure — for benefits you can't use yet.
What matters is that the monolith is modular. Keep billing, users, and your core domain in clearly separated parts of the code. If you ever need to split something out, those boundaries make it possible.
Decisions that are hard to undo
Some choices deserve real thought on day one, because changing them later is painful.
Your data model. Code is easy to rewrite; data in production is not. Spend time understanding the core entities and how they relate. A relational database like PostgreSQL is a safe default for most SaaS products — it handles structured data well and is flexible enough for the occasional JSON field.
Multi-tenancy. If you're building B2B software, decide early how organizations, users and permissions relate to each other. Retrofitting "teams" into a product designed for individual users is one of the most common and costly rewrites I see.
Authentication. Use a proven solution rather than building your own. It's a solved problem and an easy place to make serious mistakes.
Decisions you can safely postpone
- Caching layers, queues and search engines — add them when you can measure a need.
- Multiple regions and complex scaling setups.
- Splitting the frontend and backend into separate repositories.
- Perfect test coverage. Test the parts that handle money and data first.
A practical default
If you want a starting point rather than a framework for deciding: a TypeScript application (Next.js, or a NestJS API with a React frontend), PostgreSQL, a managed authentication provider, Stripe for billing, and a simple deployment on Vercel or a managed container service. It's boring, well-documented and easy to hire for — which is exactly what you want.
The goal of MVP architecture isn't to be ready for a million users. It's to make sure that if you get your first thousand, you can keep building instead of starting over.