Almost every founder who's read a few engineering blogs arrives at the first call already convinced they need microservices. It sounds like the serious, scalable choice. In practice, it's usually the choice that spends the first three months of the budget on infrastructure nobody has used yet, before a single feature a customer can see gets built.
A monolith is the correct architecture for the question an MVP is actually asking.
The problem microservices actually solve
Microservices exist to let large engineering organisations ship independently - team A can deploy their service without waiting on team B's release. That's a coordination problem that shows up once you have many teams and a system under real, uneven load. An MVP with one team and no confirmed users yet doesn't have that problem. It has a different one: finding out, as fast and cheaply as possible, whether anyone wants the thing at all.
A monolith - one codebase, one deploy - is not the beginner's version of the real architecture. It's the correct architecture for the question an MVP is actually asking. Changing a feature means changing it in one place. Debugging means reading one call stack, not chasing a request across four services and a message queue to find out which one silently swallowed the error.
What it actually costs to start distributed
Before writing a feature a user will ever see, a microservices setup needs service discovery, inter-service auth, distributed logging, and a deployment pipeline for each service instead of one. Teams routinely spend real money - tens of thousands, not hundreds - standing this up before the product itself exists. That's not scalability. It's a bet that the coordination problem will show up before the product-market-fit problem does, and for almost every early-stage product, that bet loses.
The actual sequence
Build the monolith. Structure it with clean internal boundaries - modules that don't reach into each other's internals - so the seams already exist. When (and only when) a specific part of the system is genuinely the scaling bottleneck, which is a great problem to have because it means the product works, that one part can be extracted into its own service. Everything else stays exactly where it is.
Building something like this?
Let’s connect
