You are in a planning meeting and your technical lead says the new platform should be built as microservices because it will scale better. Around the table, heads nod. The word sounds modern, robust and future-proof. So you approve it — and six months later you are wondering why a relatively simple product is costing twice the budget and shipping half as fast.
This scenario plays out constantly. Architecture decisions made to sound impressive, rather than to fit the actual business, quietly burn time and money. As a non-technical founder you do not need to write code, but you do need enough grasp of this trade-off to ask the right questions.
What a monolith is
A monolith is a single application where everything — the user interface, the business logic, the database connections — lives together in one codebase and runs as one unit. Think of it as a well-organised house: all the rooms are under one roof, and getting from the kitchen to the lounge is quick because there are no walls between buildings to cross.
Monoliths are simple to build, simple to deploy and cheap to run. For the overwhelming majority of new products, they are the correct starting point. Some of the largest software companies in the world ran monoliths well past the point most founders assume you must split them up, and several still do at enormous scale. The word has acquired an undeserved stigma — the term sounds lumbering and outdated, when in reality a well-structured monolith is the most productive way most teams can build.
The legitimate downside arrives only at scale. When the codebase grows very large and many developers are working in it at once, changes can start to step on each other, and the whole application has to be deployed together even for a small fix. These are real problems — but they are the problems of success, and most businesses never reach them.
What microservices are
Microservices break the application into many small, independent services that each handle one job and talk to each other over a network. Instead of one house, you have a street of specialist buildings — one for payments, one for accounts, one for notifications — each able to be updated and scaled on its own.
This brings real advantages at scale: independent teams can work without stepping on each other, and you can pour resources into the one service under heavy load. But every benefit comes with a cost in complexity. Those buildings now need roads, traffic control and security between them, and that infrastructure is neither free nor simple.
Monolith vs microservices compared
| Factor | Monolith | Microservices |
|---|---|---|
| Build speed (early) | Fast | Slow |
| Operational complexity | Low | High |
| Running cost | Lower | Higher |
| Team size suited | 1–15 developers | Multiple large teams |
| Best stage | Startup to growth | Large-scale, mature |
The hidden cost founders miss
The seductive pitch for microservices is flexibility. The hidden cost is operational overhead. Each service needs its own deployment, monitoring, logging and error handling. When something breaks, tracing the fault across a dozen services is far harder than finding it in one place. A small team can spend more energy keeping the plumbing alive than building the product customers actually pay for.
In our experience, premature microservices are one of the most common ways early-stage technical budgets get quietly wasted. The architecture that looked future-proof on a slide becomes an anchor in practice — slowing every feature, multiplying running costs, and demanding specialist operational skills a small team rarely has spare.
There is also a recruitment dimension founders overlook. Running microservices well requires engineers comfortable with distributed systems, container orchestration and the monitoring that goes with them. Those people are scarcer and more expensive than generalists who can ship a monolith. Choosing microservices early can quietly raise your hiring bar at exactly the moment you can least afford it.
How to make the call
Start with a monolith if
- You have a small team, certainly fewer than fifteen developers.
- You are still discovering what the product should be.
- You want to ship and learn quickly without infrastructure overhead.
Consider microservices if
- Multiple sizeable teams need to ship independently without colliding.
- Specific parts of your system have genuinely different scaling needs.
- You have the operational maturity and budget to run distributed systems well.
Notice that every signal for microservices is about size — of your team, your traffic, your organisation. None is about how innovative or serious your product is. That is the trap to avoid: ambition is not a reason to adopt microservices, and a startup choosing them to look credible is solving a problem of perception, not engineering. The credible move, far more often, is shipping a clean monolith fast and splitting it only when real growth forces your hand.
The question to ask your developers
When an agency or engineer recommends microservices, ask one direct question: what specific problem does this solve for us right now, and what does it cost us to maintain? A good partner will give you a concrete, business-grounded answer. If the reply is mostly about future-proofing and best practice with no present-day problem named, be sceptical.
The right architecture is the one that fits where your business is today while leaving room to evolve — and a well-built monolith can be split into services later, when the need is real rather than imagined. If you want a second opinion before committing, browse experienced UK teams in our web development directory and compare how they justify their recommendations. For complex platforms, it is worth shortlisting two or three from the directory for a scoping conversation before you sign anything.