How We Choose the Architecture for an MVP

When founders ask what architecture we'll use for their MVP, they often expect a long list: microservices, message queues, caching layers, maybe Kubernetes.

Our answer is usually much simpler. And that's on purpose.

In our last post, we talked about deciding what to build. This one is about how we build it, and why a simple setup is almost always the right place to start.

The over-engineering trap

It's easy to design a first version as if it already has a million users. It feels responsible. It looks impressive in a diagram.

But every extra piece has a cost. More services mean more things to deploy, more things to monitor, and more places for bugs to hide. The first version takes longer to ship, and every change afterward is slower too.

At the MVP stage, your biggest risk isn't too many users. It's building the wrong thing and not being able to change it quickly. So we design for speed of change first.

Our default stack

Most of the products we build start with the same foundation.

Next.js for the web app. It gives users fast pages, and because it can render pages on the server, search engines can read your content properly. That's a big part of how we build SEO in from day one instead of fixing it later.

NestJS on Node.js for the backend. NestJS gives the backend a clear structure from the start. Each part of your product, like users, payments, or orders, lives in its own module with clear boundaries. It's one app, but it's organized like it could become several. That matters later, and we'll come back to it.

PostgreSQL for the database. It's reliable, well understood, and handles far more than most early products will ever need. It works for structured data, flexible data, and search, so we rarely need a second database early on.

React Native for mobile, when mobile is core. If your product needs an app in the App Store and Google Play, React Native lets us build both from one codebase. Because it uses the same language as the rest of the stack (TypeScript), logic and types can be shared across web, mobile, and backend. If a mobile app isn't central to what you're testing, we often start with a responsive web app and add the mobile app once the product has proven itself.

One language across the whole product also means one team can move across all of it, which keeps things faster and cheaper, especially early on.

Three questions we ask before adding anything

Every time something new is proposed for the architecture, we ask:

What problem does this solve right now, not someday? What happens if we don't build it yet? How hard will it be to add later?

If the honest answer is "nothing breaks without it, and we can add it later," it waits. Most of the time, that's the answer.

A simple start that can grow

Starting simple doesn't mean ignoring the future. It means making choices that keep the future open.

That's why the structure matters so much. Because the NestJS backend is split into clean modules, any single part can be pulled out into its own service when there's a real reason to. We just don't do it before that reason exists.

Some real signs it's time to add more:

Pages or requests get slow under real traffic. That's when caching starts to make sense. Some tasks take too long to run during a request, like sending hundreds of emails or processing files. That's when background job queues help. The database is doing too much work. Better indexes come first, then read replicas if needed. The team grows, and different groups need to ship independently. That's when splitting into separate services can pay off.

Each of these is a response to something real, measured in your product. Not a guess made before launch.

What this means for you

A simple, well-structured architecture means your product launches sooner and costs less to build. Changes after launch are quicker, because there are fewer moving parts. And when you hire your own team later, they inherit a codebase built on popular, well-documented tools that they can understand quickly.

Good architecture isn't about building for a million users on day one. It's about not blocking yourself when you get them.

Planning your product?

If you're working out how to build your first version, we're happy to talk it through. Start with how we scope an MVP, or tell us about your idea.