Microservices for Business Web Apps: When You Need Them (Usually You Don't)

Microservices are a way of building a web application as a set of small, separate programs, each running on its own and talking to the others over a network. A monolith is the opposite: one application, one codebase, one thing to deploy. For most growing businesses the honest answer to the microservices question is no, you do not need them. A well-built monolith is cheaper to build, cheaper to host and far easier to maintain, and it will handle more traffic than the vast majority of business web apps will ever receive.

Microservices solve real problems, but they are problems most SMEs do not have: dozens of developers tripping over each other in one codebase, or one part of a system under wildly different load from everything else. If a development partner has proposed a microservices architecture for your web app, this guide explains what you are being sold in plain terms, what it genuinely costs to run, the few signals that justify it, and the questions that reveal whether the proposal serves your business or the invoice.

Microservices in plain English: a food court versus a single kitchen

A monolithic application is a restaurant with one kitchen. One head chef, one set of suppliers, one gas bill. Orders go in, food comes out, and when something goes wrong you know exactly which kitchen to walk into.

A microservices architecture is a food court. The burger stall, the noodle stall and the coffee stall each have their own staff, their own till and their own suppliers. If the coffee stall closes, burgers keep selling. That independence is the whole appeal. But a customer who wants a full meal now stands in three queues, and somebody has to manage the shared seating, the cleaning rota and the arguments between stall owners. The coordination does not disappear. It just moves, and it gets a payroll of its own.

In software terms: instead of one application handling accounts, orders, invoicing and email, you run four or more separate programs, each with its own database, its own deployment pipeline and its own monitoring. They coordinate through network calls, and every one of those calls can be slow, can fail, and must be secured. Every service is one more thing to host, patch, watch and pay for.

The threshold test: do you have a problem microservices actually solve?

Microservices were popularised by Amazon and Netflix, companies employing thousands of engineers on a single product. The architecture solved a people problem before it solved a technical one: how do you let hundreds of teams ship changes without queueing behind each other? Splitting the system into pieces, each owned by one team, answered that. It was never mainly about making small systems faster.

Now the counterexamples. Stack Overflow, one of the busiest websites in the world, famously runs as a monolith on a small number of servers. Shopify, which absorbs some of the largest sales spikes on the internet every November, runs a deliberately modular monolith. Basecamp has argued for the monolith in public for years. None of these companies is short of engineering talent or money. They stay with one application because it is the better tool for a focused team.

Here is the honest threshold test. Microservices start to earn consideration when at least one of these is true:

• Team size: you have several full development teams, roughly eight or more engineers, genuinely blocking each other inside one codebase.
• Wildly uneven load: one component, such as video processing or a public API, carries demand that dwarfs the rest and must scale on its own.
• Separate release schedules: parts of the system must ship on genuinely different cycles with different risk profiles, and coordinating releases is causing real, recurring pain.
• Forced isolation: a regulator, a client contract or a security boundary requires one part of the system to run separately.

If none of those applies today, the test is failed and the conversation should end there. A product maintained by two to six developers does not have the coordination problem this architecture exists to fix, and adopting it anyway means paying the costs of a thousand-engineer company on a six-person budget.

The costs a microservices proposal rarely itemises

Every proposal will list the benefits: independent scaling, fault isolation, technology flexibility. All real, at the right scale. Here is the other column of the ledger.

Hosting stops being one line on a bill

A monolith runs on one server or one managed platform, and a competently built business app sits comfortably on a modest virtual server costing tens of pounds a month. The microservices version of the same app needs multiple services, an orchestration platform such as Kubernetes to keep them running, a load balancer, usually a message queue, and a centralised logging and monitoring stack so anyone can tell what is happening. Each piece is a monthly cost before you count a single hour of the engineering time needed to look after it.

You are hiring for DevOps whether you meant to or not

Somebody has to own the deployment pipelines, the cluster upgrades, the certificates and the 2am alerts. With one application that duty is small enough for the developers themselves to carry. With a distributed system it becomes a standing role: either a hire, or a permanent retainer with the agency that built it. Notice that second option carefully, because the party recommending the architecture is often the party who would hold the retainer.

Debugging gets slower and dearer

In a monolith, an error produces one stack trace in one log file, and a developer can usually reproduce the whole failure on a laptop. Across services, the same bug becomes an investigation: which service failed, which call chain triggered it, in what order, with what data in flight. Distributed tracing tools exist to answer those questions, but they have to be bought or configured and understood, and the hours spent doing that are billed to you.

Ordinary features cost more, forever

Adding a discount code field to a monolith is one change and one deployment. In a distributed system the same request might touch the orders service, the pricing service and the checkout front end: three changes, three deployments, an updated contract between services and a coordination conversation. That tax is not paid once at build time. It is paid on every feature for the life of the system.

The pool of people who can maintain it shrinks

A great many capable developers can pick up a well-organised monolith in a mainstream language. Far fewer can confidently operate a Kubernetes cluster and a fleet of interdependent services. If the relationship with your build partner sours, replacing them becomes harder and more expensive, and they know it. Supplier dependency belongs in the decision alongside the technical merits.

The sensible default: a modular monolith

The genuine best practice for a growing business web app is not a pile of services. It is one application organised internally into clean modules with clear boundaries: accounts code here, billing code there, no reaching across. You get most of the maintainability that microservices promise with none of the network overhead, the orchestration platform or the standing DevOps bill.

It also keeps the door open. A well-organised monolith lets you carve out the one genuinely hot component later, when usage data proves the need, and extract it as a single service. That is a bounded, affordable job. Merging a dozen prematurely split services back into one application is the opposite: expensive, risky and so painful that it almost never happens. Teams simply live with the mistake. This is how we build web applications at BoldCrafter, and our web design and development service is structured around exactly this principle: modular from day one, distributed only when the numbers demand it.

Two related decisions are worth separating from the architecture question. If speed is the worry driving the microservices conversation, measure before you re-architect anything, because most slowness in business websites comes from images, scripts and hosting rather than application architecture; our website performance guide for UK businesses covers what actually moves the speed scores Google measures. And if you are still deciding what to build on in the first place, platform comes before architecture; our comparison of custom web development versus WordPress deals with that choice.

Six questions to ask a partner proposing microservices

None of these requires technical knowledge. The answers, and the speed and confidence with which they arrive, will tell you most of what you need to know.

1. What specific problem in our current system does this solve that a modular monolith could not? Insist on a named, current problem, not a hypothetical future one.
2. How many services, and what will the full setup cost to host each month at our current traffic? A serious proposal has this number ready.
3. Who watches this at 2am, and what does that cover cost per year? If the answer is a retainer with the proposer, weigh the recommendation accordingly.
4. How many other local firms or freelancers could take this over if we parted ways? You are buying a dependency as well as a system.
5. What would the same scope cost as a monolith, and what exactly does the difference buy us? Make the premium explicit and make them defend it.
6. Can we start modular and extract a service later if the data justifies it? If the answer is no, ask why the reversible option is off the table.

A good partner will answer all six without flinching, and the best ones will have raised half of them before you did. Vagueness on the first question and silence on the second and third are the classic shape of a proposal built around the seller's interests.

Get a straight second opinion before you sign

If a microservices proposal is sitting on your desk, the cheapest insurance available is an independent read of it. Send it over and we will tell you in plain English whether the architecture matches the problem, what it will cost you beyond the build quote, and whether a simpler shape would serve the business better.