Cargo-Culting the Architecture of Giants
At some point in the last decade, "microservices" stopped being an architectural choice and became a status symbol. Founders and engineering leaders adopted them not because their problem demanded it, but because the biggest names in technology used them, and imitating the architecture of giants felt like a shortcut to being one. It is one of the most expensive cases of cargo-culting in modern software: copying the visible artifacts of companies operating at a scale you do not have, and inheriting all of their costs while capturing none of their benefits.
The hard truth for most B2B SaaS companies is this: microservices were the answer to a problem you almost certainly do not have yet, and adopting them early does not prepare you for scale — it actively slows you down on the road to reaching it. The architecture that serves a company with thousands of engineers and hundreds of millions of users is not a smaller version of what serves your team of twelve. It is a different thing entirely, solving different problems.
Key takeaway: You do not have Google's problems, so you should not pay for Google's architecture. Right-sizing is not settling for less — it is refusing to buy complexity you cannot use.
Why Microservices Became the Default
Microservices exist to solve organizational and scaling problems that only appear at genuine size: hundreds of engineers who cannot coordinate on one codebase, components that need to scale independently by orders of magnitude, and teams that must deploy dozens of times a day without stepping on each other. For a company with those problems, splitting the system into independently deployable services is liberating.
For a company without them, every one of those "benefits" inverts into a cost. You have added network boundaries between things that used to be a simple function call. You have turned a debugging session into a distributed-tracing investigation. You have replaced one deployment with fifteen, one database with twelve, and one clear codebase with a constellation of repositories that no single person fully understands. You bought the medicine for a disease you do not have, and the side effects are now your daily reality.
The Hidden Tax of Premature Distribution
Splitting a system across the network before you need to imposes three compounding taxes that quietly drain a young company's most precious resource: speed.
The complexity tax
A single logical operation that once lived in one place now hops across several services, each with its own deployment, database, and failure modes. Simple questions — where did this request fail, why is this number wrong — become forensic exercises. The cognitive load of holding the system in your head, the thing that makes small teams fast, evaporates.
The operational tax
Every service is a thing to deploy, monitor, secure, back up, and keep alive. Multiply the boilerplate of running one service by fifteen and you have a full-time operational burden that produces zero customer value. Small teams end up spending their scarce engineering hours babysitting infrastructure instead of building the product that pays the bills.
The velocity tax
The most damaging cost is the slowest to notice. A feature that touches three services now needs three coordinated changes, three deployments, and careful management of the contracts between them. What would have been an afternoon in a single codebase becomes a multi-day, cross-service negotiation. The architecture chosen to enable scale becomes the reason you cannot ship fast enough to reach it.
The Distributed Monolith: The Worst of Both Worlds
Premature microservices usually do not even deliver the independence they promise. When services are carved up along the wrong boundaries — which is almost inevitable early, before you understand your own domain — they end up so tightly coupled that you cannot deploy one without deploying the others. This is the distributed monolith: a system that has all the operational overhead and network fragility of microservices, plus all the coupling and coordination pain of a monolith, with none of the upside of either. It is the single most common and most costly outcome of adopting microservices too early, and once you are in it, unwinding it is brutally expensive.
The Modular Monolith: Right-Sizing for Reality
The architecture quietly winning back serious engineering teams is the modular monolith — and it is not a step backward. A modular monolith is a single deployable application with strong internal boundaries: clearly separated modules with well-defined interfaces, organized around business domains, that are simply not distributed across the network. You get the clarity and speed of a single codebase and a single deployment, with the clean internal structure that keeps the system maintainable as it grows.
Crucially, it keeps your options open. Because the modules are already cleanly separated by clear interfaces, the day a specific component genuinely needs to scale independently, you can extract it into its own service with far less pain — you have already done the hard conceptual work of drawing the boundaries. You get to defer distribution until you have real evidence you need it, and real understanding of where to cut. That is right-sizing: the simplest architecture that solves today's problem without foreclosing tomorrow's.
When You Actually Should Split
This is not an argument that microservices are wrong — it is an argument for evidence over fashion. There are real signals that justify extracting a service:
- A different scaling profile: a specific component that must scale independently and is straining the rest of the system.
- Genuine team friction: an organization large enough that teams are truly blocking each other in one codebase.
- Different reliability or compliance needs: a piece with radically stricter uptime, isolation, or regulatory requirements.
- A proven, stable boundary: a seam that has held firm over time, so you know exactly where to cut.
How We Right-Size an Architecture
When we assess a B2B SaaS architecture, the goal is never to reach a predetermined pattern; it is to match the architecture to the company's actual stage, team, and scaling reality. We map the real domains and their boundaries, identify which components (if any) have genuinely different scaling or reliability needs, measure where the team is actually losing velocity, and recommend the simplest structure that removes that friction while leaving clean seams for future extraction. Often the highest-value move for a struggling early-stage team is to consolidate a premature, painful microservices sprawl back into a well-structured modular monolith — and watch their delivery speed double.
The Strategic Payoff
Architecture is not a badge of sophistication; it is a tool for moving fast and safely at your actual scale. Right-size it and your small team ships quickly, reasons about the system easily, spends its hours on product rather than plumbing, and retains the ability to distribute later when the evidence demands it. Over-build it in imitation of companies whose problems you have not yet earned, and you spend your most fragile years fighting your own infrastructure. The companies that win are rarely the ones with the most fashionable architecture. They are the ones whose architecture let them move fastest toward the scale that would eventually, genuinely, justify something more.
Claim One of This Month's Three Slots
We take on only three new projects each month, and right-sizing a B2B SaaS architecture — knowing exactly what to build now and what to defer — is precisely the kind of senior judgment those slots exist for. If microservices sprawl is slowing your team down, or you are about to choose an architecture and want to get it right the first time, book a Strategic Architecture Call. We will assess your real scaling needs, flag where complexity is costing you velocity, and give you a concrete plan for an architecture sized to your actual stage — whether or not you build it with us.
