What is a monolith in software?

A monolith is a single application where all the parts of your product live in one codebase and run together as one program. Adding a feature means adding to that one thing. For most early-stage startups it is the simplest and fastest way to build, because there are fewer separate parts to manage and reason about.

What are microservices?

Microservices split an application into many small, separate programs that each do one job and talk to each other over the network. Instead of one thing to run, you have many, each deployed and scaled on its own. This can help large teams and systems, but it adds a lot of complexity that a small team pays for whether or not they need it.

Should an early-stage startup use microservices?

Almost never at the start. Microservices solve problems that come with large teams and large scale, and an early-stage startup has neither. Starting with them means paying a heavy complexity cost up front to solve problems you do not have yet, which slows down the thing that matters most early: finding out what to build.

Why is a monolith the right first choice?

Because it is faster to build, easier to understand, and simpler to change while you are still figuring out your product. Early on, the biggest risk is building the wrong thing, not running out of scale. A monolith lets you change direction quickly and cheaply, which is exactly what an early product needs.

What is the real cost of premature microservices?

You take on the work of running many separate programs, handling network calls between them, tracing bugs across service boundaries, and keeping data consistent when it is split apart. That is a large, ongoing cost to a small team's time, spent solving scaling problems you may never actually reach.

Can a monolith scale?

Yes, much further than people assume. Many large, successful products ran on a single well-built application for years. A monolith can be split into cleanly separated parts inside one codebase, and you can scale it by running more copies of it. Real scale limits usually arrive much later than teams fear.

When does splitting into services actually make sense?

When you have clear, repeated problems that services would solve: a specific part of the system needs to scale very differently from the rest, or separate teams keep blocking each other in one codebase, or one component has genuinely different reliability needs. Split in response to real problems you can name, not in anticipation of them.

How do I keep a monolith from becoming a mess?

Keep clean boundaries inside it. Organize the code into clear modules that map to parts of your product, and keep them from using each other's internal code. A well-organized monolith with clear divisions is easy to work in, and those same divisions make it far easier to split later if you ever need to.

What happens if I start with microservices and it was the wrong choice?

You spend your early, scarce engineering time managing infrastructure and network problems instead of building and learning. Worse, splitting the system early fixes in place boundaries you set before you understood the product, and those boundaries are usually wrong, so you pay to move them later. It slows down the whole company at the stage where speed matters most.

Is this only about startups?

The core idea, start simple and add complexity only when real problems require it, applies broadly. But it matters most for early-stage startups because they have the least time and the least certainty about what they are building. A large company with many teams and huge scale has different constraints and may genuinely need services.

How does Reveneau approach this for early-stage clients?

We default to a well-structured monolith with clean internal boundaries, because it gets a real product to users fastest and keeps change cheap while the product is still changing. We only split into services when a client has a real, specific problem that splitting actually solves, and we build the monolith so that splitting later is straightforward.

Monolith vs microservices early on: Reveneau

We meet the same well-built product more often than you would think. A small startup, a handful of engineers, a product with barely any users yet, and an architecture split into a dozen separate services talking to each other over the network. Someone made that choice early because it felt like the professional thing to do, the way real companies build. And now that small team spends a large share of its time not building the product but keeping the systems running: deploying many things instead of one, chasing bugs that cross service boundaries, and joining data back together that they split apart. They solved a scaling problem they did not have and created a speed problem they very much do. For almost every early-stage startup, the right first choice is one well-built monolith, and it is worth being clear about why.

What these two words actually mean

Quickly, so the rest makes sense. A monolith is a single application. All the parts of your product live in one codebase and run together as one program. When you add a feature, you add it to that one thing. There is one thing to build, one thing to deploy, one thing to run.

Microservices are the opposite design. You split the product into many small, separate programs, each doing one job, each running on its own, and they talk to each other over the network. Instead of one thing to run, you have ten. Each one is simple on its own, but the system as a whole is now a network of programs that have to find each other, call each other, and stay in agreement about shared data. That network is where the cost is, and it is a cost you pay every day, not just once.

Microservices solve problems an early startup does not have

Here is the part that gets lost. Microservices are not a general upgrade over a monolith. They are a specific solution to specific problems, and those problems come from being big, not from being new.

The main problem they solve is many teams working in one codebase and constantly getting in each other's way. When you have two hundred engineers, splitting the system so each team owns its own service lets them move without waiting on everyone else. The second problem is parts of a system that need to scale very differently: one component gets a thousand times the traffic of another, and it is wasteful to scale the whole thing together. Splitting lets you scale just the busy part. These are real problems, and for a large company microservices are often the right answer to them.

An early-stage startup has neither problem. It does not have many teams. It has one small team who could all fit around a table. It does not have parts of the system under different levels of load, because it barely has load at all. So starting with microservices means paying the full price of the solution while having none of the problems it solves. You get the complexity and the daily cost, and in return you get nothing, because what it gives you is not something you need yet.

The real cost is speed, and speed is what you cannot spare

The reason this matters so much for early startups, more than for anyone else, is that their scarcest resource is the ability to change direction quickly. At the start, your biggest risk by far is not that your product will stop working from too many users. It is that you will build the wrong product. The whole early stage is about learning what to build, and that means changing your mind, often and cheaply. We wrote about that core challenge in knowing what to build.

A monolith is fast to change. Everything is in one place, so changing a feature or moving a boundary is a normal edit. Microservices make change slow and heavy. A change that touches two services now means coordinating two deployments, handling the moment when one is updated and the other is not, and reasoning about failures across the network between them. Early on, when you are rewriting large parts of your product as you learn, that extra work shows up on every single change. You have made the most common activity of an early startup, changing your mind, expensive.

There is a less obvious mistake too. When you split into services early, you have to decide where the boundaries go, which parts are separate from which. But you are setting those boundaries before you understand your own product, because you have not built it or learned from users yet. Those early boundaries are almost always wrong, and a wrong boundary in a microservice system is painful to move: it means separating programs that are now split across the network. So you fix your least-informed guesses in place at the exact stage you should be keeping everything easy to change.

A monolith scales further than people fear

The usual objection is that a monolith will not scale, so you should build for scale now. This gets the timing exactly backward, and it overestimates how soon real scale limits arrive.

Many large, successful products ran on a single well-built application for years, well past the point most founders assume they would have needed to split. You can scale a monolith a long way simply by running more copies of it behind a load balancer. And a monolith does not have to be disorganized inside. You can organize it into clean, separate modules that map to the parts of your product, with clear divisions between them, so it stays easy to work in as it grows. Keeping those divisions clear is the single best thing you can do for your future, because it keeps the code manageable now and makes splitting off a real service later straightforward if you ever truly need to.

Building for a scale you do not have is a choice that works against you. It assumes you will succeed so fast, that scale becomes your problem before product-market fit does. For nearly every startup that is not how it goes, and paying the cost of microservices up front just to be ready for a problem you may never reach is a poor use of the little time you have. If anything, the discipline is to release the smallest real thing first and let real results tell you what to build next, which is the same idea behind how to launch a product with minimal resources.

When splitting actually makes sense

None of this means microservices are wrong forever. It means you split in response to real problems, not in anticipation of them. There are clear signals, and you will recognise them when they happen.

Split when one part of your system genuinely needs to scale very differently from the rest, and running more copies of the whole application is clearly wasteful or not enough. Split when separate teams have grown to the point where they keep blocking each other in one codebase, and giving a team its own service would let them work independently. Split when one component has truly different reliability needs, where you want to isolate it so a problem there cannot stop everything else. In each case there is a specific, repeated problem you can name, and pulling that one piece out into its own service is the direct fix for it.

That is the whole rule, and it is simple: split off a service when you have a concrete problem that splitting solves, one piece at a time, and not before. This is the same instinct behind releasing in small safe steps and not breaking the product, which we wrote about in move fast without breaking the product. Add complexity only when real problems require it.

So for the early-stage startup deciding how to begin, the answer is almost always the simple one. Build one well-structured monolith with clean boundaries inside it. Keep it easy to change while you are still learning what your product should be. Scale it by running more of it. And when, and only when, you have a real problem that a service would fix, separate that one piece. Start simple, stay fast, and let the need for microservices prove itself before you pay for them.

Faster building does not change this answer, and it is worth saying why, because it is tempting to think the opposite. Generating eight services is now about as easy as generating one, which removes the effort argument for staying with a monolith. But effort was never the real argument. The reason to stay with one service early is that distributed systems are harder to reason about, harder to debug, and harder to change safely, and none of that got easier. The cost of microservices was always operational and cognitive, not the typing. Cheap typing is not a reason to take on an expensive architecture.

Monolith vs microservices for an early-stage startup