You sat through a tech talk, or read a thread that went viral, and now you've got a sentence stuck in your head: "I want my product built with microservices from day one." That's a completely reasonable sentence if you work at a company with hundreds of developers spread across dozens of teams. It's a very expensive sentence if your team is three or four people and you haven't even shipped the first version yet.
This is the conversation we end up having with a good chunk of the founders who come to us with that idea already set in stone, almost always picked up from a talk or an article describing the architecture of a company that looks nothing like theirs. It's not that microservices is a bad architecture — it's a tool that solves a very specific problem, and odds are that problem isn't yours yet.
What a Monolith Is, in Plain Terms
A monolith is your entire product living in a single application: the frontend, the business logic, the database connection, all together, in one codebase that deploys as a single unit. When you make a change and run the deploy, the whole product updates at once.
It's not a synonym for outdated architecture or bad practice, even though the word "monolith" sounds like a heavy rock that's hard to move. It's simply the most direct way to build software: everything in one place, everything talking to everything else inside the same process with no network involved, everything deployed together with every update.
What Microservices Are, in Plain Terms
Microservices splits that same product into independent pieces: one service for payments, another for users, another for notifications, each with its own code, sometimes its own database, and its own deployment cycle. Instead of calling each other like functions inside the same program, they talk over the network — HTTP, message queues — as if they were separate applications having a conversation.
The promise is real: each piece can be scaled, updated, or even rewritten without touching the others. The catch is that independence isn't free — you pay for it in infrastructure and in coordination that didn't exist before.
The Comparison at a Glance
| Monolith | Microservices | |
|---|---|---|
| Speed to launch | Fast — one app, one deploy | Slow — you need to stand up and connect several services before anything runs |
| Infrastructure cost | Low — one server or one managed instance is enough | High — every service needs its own hosting, monitoring, and sometimes its own database |
| Operational complexity | Low — one log, one deploy pipeline | High — orchestration, service discovery, versioning contracts between APIs |
| Changing your mind about the product | Easy — moving logic between modules is just editing files | Hard — changing how two services relate means touching contracts and deployments on both sides |
| Where it scales best | Small and mid-sized teams, loads that don't justify splitting | Large teams working in parallel, or parts of the system with very different scaling needs |
The Myth to Bust: "More Professional" Isn't a Reason
Here's the point most worth clarifying: microservices isn't "more professional" or "better" in the abstract. It's a tool that exists to solve two specific problems: large teams that need to work in parallel without constantly stepping on each other's code, and parts of a system with scaling needs so different from each other that it makes sense to scale them separately — a video-processing service that needs 50 instances while the rest of the product needs 2, for example.
If your team is three to eight people, that first problem — coordinating large teams so they don't collide — simply doesn't exist yet. You'd be running an architecture built for a problem of a different scale, and that mismatch costs you time and money, not technical prestige.
Why Starting an MVP With Microservices Is a Costly Mistake
Starting a new product with microservices is almost always an expensive mistake, and not out of some bias against the architecture — it's simple arithmetic:
- More development time. Every call between services needs a defined contract, network error handling, retries, versioning of internal APIs. That's weeks of infrastructure work before you write the first feature a user will actually see.
- More infrastructure to maintain. Instead of one deploy and one log, you have several services running, each with its own monitoring, its own alerts, its own CI/CD pipeline.
- Harder debugging. A bug is no longer just "in the code" — it can live in the communication between two services, in a network timeout, in an out-of-sync contract version. Finding it takes longer with a small team and no dedicated DevOps.
- All of this to solve a problem — coordination across large teams — that a team of three or four people doesn't have in the first place.
The typical outcome we see when a founder insists on microservices from day one: months of extra development, a monthly infrastructure bill that doesn't match the actual number of users the product has, and a launch date pushed far enough out that validating whether anyone wanted the product takes that much longer too.
The Real Path: A Well-Organized Monolith, Split Only When It Hurts
The alternative isn't "messy monolith" versus "tidy microservices." It's a modular monolith: the whole product lives in a single application, but the code is organized by domain — one folder for payments, another for users, another for notifications — with clear boundaries between modules even though they share the same deployment. This gives you most of the organizational clarity of microservices without paying the cost of running several distributed systems from day one.
That's where we start on practically every MVP we build at Cambalache Studio. Splitting into microservices comes later, when one specific piece of the system genuinely needs it: because it carries a completely different traffic load than the rest (an image or video processor, for instance), because a new team joins and needs to work on that piece without blocking everyone else, or because a specific technical requirement — a different language, a particular scaling need — justifies it. That's when you extract that piece into its own service, backed by real evidence of why it's needed, not because "that's how the big companies do it."
Conclusion
The question isn't which architecture is better — it's which one solves the problem you actually have today. If your team is small and you're still validating that the product makes sense, a well-organized, domain-modular monolith gets you to production faster, cheaper, and with fewer moving parts that can break. Microservices are for when the real problem — large teams coordinating, or parts of the system with very different scaling needs — actually shows up, not before. It's the same logic behind the difference between an MVP and a full product: you use the tool that fits the stage you're at, not the one that sounds best in a talk. If you're also figuring out where to host that monolith and which backend to run it on, Vercel vs AWS is the logical next step in that decision.