Monolith vs microservices: which does your product actually need?

What each approach really is

• A monolith — one well-organised application and database. Simple to build, deploy, test and reason about.
• Microservices — many small services, each owning its data, talking over the network. Powerful at scale, heavy in overhead.
• The middle ground — a clean, modular monolith you could split later if you ever need to.

Why most startups should start with a monolith

Microservices add network calls, distributed data, more moving parts to deploy, and a whole category of failures that simply don't exist in a monolith. For a team that's still finding product-market fit, that's a tax on every feature. You move slower precisely when you most need to move fast.

The good news: a well-structured monolith with clear internal boundaries can be carved into services later — if and when real scale or team size demands it. Starting simple doesn't paint you into a corner; starting complex often does.

When microservices genuinely earn their keep

• Many teams need to deploy independently without stepping on each other
• Distinct parts of the system scale very differently (e.g. a heavy media pipeline vs a light API)
• You have the DevOps maturity to run and observe a distributed system