The Monolith: Start Here

"Almost all of the successful microservice stories have started with a monolith that got too big and was broken up." — Martin Fowler, Monolith First

"Monolith" gets used as a pejorative. It shouldn't be.

What a Monolith Actually Is

When you run git init and npm init, you have a monolith. One folder, one codebase, one deploy process. That's it.

The monolith is the default — and the default exists for a reason. Every piece of tooling, every CI/CD platform, every deployment pipeline is built around the single-repo, single-deploy model. GitHub, Vercel, Netlify — they all think in terms of one repo, one deploy.

A monolith means:

• One codebase — routing, state, styles, tests, and dependencies all live together
• One deploy process — one CI run, one artifact, one rollout
• Tight coupling — which sounds like a bad thing, but also means the entire system can be verified in a single build

That last point matters more than it seems. When routing, state, and data fetching all live in the same codebase, a single CI/CD run can verify that they all work together. With distributed systems — microfrontends, separate backend services — you lose that guarantee. Things can work in isolation and break in production.

Simplicity Is a Feature

There's a tendency in software engineering to equate complexity with sophistication. More moving parts must mean a more mature system. It doesn't.

I've seen setups where a Docker configuration was so elaborate it had to run from a data center — you connected to it remotely, and if it went down you couldn't make a CSS change. The explanation was always some version of "it has to be this way." In my experience, if you ask "why?" enough times, you usually find out it doesn't have to be that way at all.

The monolith avoids most of this. No coordinating releases across services. No "the API team needs to ship first." No migration windows. Everything moves together.

When to Start a Monolith

If you're starting something new: start with a monolith.

You don't yet know where the team boundaries will fall. You don't know which parts of the product will grow fast and which will stay stable. You don't know which modules will need to deploy independently. The monolith lets you discover those boundaries from real usage — rather than guess at them upfront and embed wrong guesses into your architecture.

Conway's Law says that systems mirror the communication structure of the organizations that build them. That's often invoked as a warning, but it's also a useful signal: once you know the shape of your team, you can shape your architecture to match. The problem is you can't do that before the team exists.

The Catch

The monolith's strength — everything in one place — eventually becomes its constraint.

As the codebase grows:

• Team collisions increase — more developers touching the same files means more merge conflicts
• CI/CD slows down — running every test on every change gets expensive
• Ownership blurs — it becomes hard to say who's responsible for what when everything is interleaved
• Deploy risk grows — a bug anywhere can take down everything

These are real problems. But they're also problems that only emerge at scale. Solving them before they exist is over-engineering. The monolith will tell you when it's ready to be broken up — usually loudly, through the friction of trying to ship.

What Comes Next

When the monolith starts fighting you — slow builds, team collisions, deployment risk — that's when the tradeoffs of more distributed architectures start to pay off. But those architectures come with their own complexity. More autonomy across teams means more coordination overhead. More independent deployments means more surface area for things to diverge.

The architecture that works is the one that matches where you actually are — not where you might be in three years.

Start simple. Move deliberately. The architecture should follow the product, not the other way around.