Most small and mid-size businesses should choose a well-structured monolith, ideally a "modular monolith" with clear internal boundaries. It is cheaper to build, simpler to host and far easier to debug. Microservices pay off when several independent teams need to release separately, or when parts of the system have very different scaling or compliance needs.
Microservices became fashionable because large technology companies use them, and many proposals now recommend them by default. But architecture should follow the size of your team and the shape of your problem, not the habits of companies with hundreds of engineers. This guide explains both approaches in plain English and gives you clear rules for choosing. Architecture is one part of a bigger set of build decisions, all covered in our custom software development guide for 2026.
What is a monolith?
A monolith is a single application that contains all of your software's features in one codebase, deployed as one unit. Customer accounts, orders, invoicing and reporting all live in the same program and usually share one database.
"Monolith" sounds old-fashioned, but it simply means "one piece". Plenty of successful products run as monoliths. The problems people associate with them, such as tangled code where changing one feature breaks another, come from poor internal organisation, not from being a single application.
What are microservices?
Microservices split an application into many small, separate services, each responsible for one business function and usually with its own database. The services talk to each other over a network through APIs.
So instead of one application, you might have an accounts service, an orders service, a payments service and a notifications service, each deployed independently, possibly written in different languages and owned by different teams.
What is a modular monolith?
A modular monolith is one application, deployed as one unit, but organised internally into clearly separated modules with defined boundaries between them. It is the middle ground, and for most growing businesses it is the sweet spot.
Each module (say, CRM, invoicing and a client portal) owns its own logic and data, and talks to other modules only through defined interfaces. You get most of the organisational benefits of microservices without the operational overhead. And if one module later needs to become a separate service, its clean boundaries make that extraction much easier.
Think of a modular monolith as microservices-ready, without paying the microservices bill up front.
How do the two approaches compare?
The trade-off is simplicity against independence. This table shows how they typically differ for a small or mid-size business.
| Factor | Monolith (modular) | Microservices |
|---|---|---|
| Initial build cost | Lower | Higher: more infrastructure, communication and setup |
| Hosting and operations | Simple: one app, one database, one deployment | Complex: many services, monitoring, networking, orchestration |
| Debugging | Easier: one place to trace a problem | Harder: a request may pass through several services |
| Deployment | Whole app deploys together | Each service deploys independently |
| Scaling | Scale the whole app; usually fine for most workloads | Scale individual parts that need it |
| Team fit | One team, or a few people | Several teams that need to work and release independently |
| Data consistency | Straightforward within one database | Harder: data spread across services must be kept in sync |
| Failure modes | Fewer moving parts | Network failures between services become a new category of bug |
| Best for | MVPs, internal tools, most SaaS and business platforms | Large platforms with many teams or very uneven workloads |
Why do microservices cost more?
Microservices cost more because every boundary between services becomes something you have to build, run and monitor. What would be a simple function call inside a monolith becomes a network request that can be slow, fail or arrive twice.
The extra work includes:
- infrastructure to run and connect many services;
- centralised logging and tracing, so you can follow one customer's request across services;
- handling partial failures, such as payments working while notifications are down;
- keeping data consistent when each service has its own database;
- more complex testing, because services must be tested together as well as separately;
- people who understand all of the above.
For a business with one development team, this overhead often consumes a large share of the effort that should be going into features. For scale, an MVP typically lands somewhere around US$15k–50k and a mid-size platform around US$50k–150k (estimates; scope drives the real figure). Starting with microservices tends to push a project towards the top of its range, or beyond, without adding anything users can see.
Hosting bills also tend to rise, since you are running many components instead of one. Our comparison of cloud hosting options for business software explains how architecture affects those costs.
When do microservices actually make sense?
Microservices make sense when organisational or technical pressures outweigh their cost. Look for at least one of these conditions:
- Several teams need to release independently. If one team's changes keep waiting on another's, separate services can remove that bottleneck.
- Workloads are very uneven. For example, a video-processing feature needs heavy computing power while the rest of the app is light. Isolating it lets you scale just that part.
- Different parts have different rules. A payments or health-data component with strict compliance requirements may be easier to secure and audit on its own.
- A component needs a different technology. Machine learning work in Python alongside a business app in another language, for instance.
- Part of the system is genuinely reusable as a product. A service that other applications, or other companies, will call.
If none of these apply, microservices are likely to cost you more than they save.
What about serverless functions?
Serverless functions are small pieces of code that run on demand on a cloud platform, and you pay only when they run. They are a useful tool alongside a monolith, not necessarily a full architecture.
A common pattern is to keep the core business app as a monolith and use serverless functions for specific background jobs, such as resizing images, processing webhooks from a payment provider or sending scheduled reports.
How do you know when to split a monolith?
Split when you feel specific, recurring pain, not when the codebase simply gets bigger. Signals include:
- deployments regularly blocked because unrelated changes are bundled together;
- one module's heavy load slowing everything else down;
- separate teams constantly stepping on each other in the same code;
- a component needing different security or compliance treatment.
When you do split, extract one service at a time, starting with the module that has the cleanest boundary and the clearest benefit. This is the same gradual approach used in legacy work, sometimes called the strangler fig pattern; our guide to legacy software modernisation: rebuild, refactor or replace explains it step by step.
How does this fit with choosing a tech stack?
Architecture and tech stack are related but separate decisions. You can build a monolith or microservices with almost any mainstream language. Choose the stack first for hiring, support and fit, then pick the simplest architecture that meets your needs. Our plain-English guide to choosing a tech stack covers that first decision.
Frequently asked questions
Is a monolith outdated?
No. A well-organised monolith is a modern, sensible choice for most business software. Many established products run on monoliths. The real problem to avoid is a poorly structured codebase, which can happen in either architecture.
Can a monolith handle growth?
Usually, yes. A monolith can run several copies behind a load balancer, use caching and move slow work into background jobs. Most small and mid-size businesses will not outgrow a well-built monolith for a long time.
Will starting with a monolith mean an expensive rewrite later?
Not if it is built as a modular monolith with clear boundaries. Those boundaries let you extract individual services later, one at a time, without rewriting everything. A rewrite is usually needed only when the original code was poorly structured.
Why do some agencies recommend microservices for small projects?
Sometimes because it is what their team prefers, sometimes because it sounds advanced, and sometimes because it means more work to bill. Ask them which specific problem microservices solve for your project. If the answer is vague, ask for the monolith option and compare.
Are microservices more secure?
Not automatically. They can isolate sensitive components, which helps, but they also create more network connections and more places to misconfigure. Security depends far more on good practices than on architecture style.
Need help choosing an architecture?
If a proposal recommends an architecture you are unsure about, we can review it with you and explain the trade-offs in plain terms. Our services page shows the kinds of systems we build; when you are ready, request a fixed-price architecture plan matched to your team and budget.