A founder asked me last year to review the architecture his agency had pitched. Eleven services. A message queue. A service mesh. The product was a booking tool with a calendar and a checkout screen, and it had no users yet.

That's the trap in one screenshot. The architecture question shows up early, it sounds like an engineering footnote, and it quietly sets your hosting bill, your shipping speed, your hiring plan, and how much sleep you'll trade for 2am pages. Monolith or microservices is not a small decision. So before you hand a full-stack development company a budget and a buzzword, it pays to know what each one really costs you.

Just build the monolith (most of the time)

One codebase. One thing to deploy. One database. It's boring, and boring is underrated.

This isn't me being a Luddite. Martin Fowler made the "MonolithFirst" case back in 2015, and it has aged well: on day one you don't know your own domain boundaries well enough to split them in the right spots. Cut too early and you cut wrong, then you're paying to move walls that should never have gone up. DHH, who wrote Rails, has a name for the opposite instinct. He calls it the Majestic Monolith, and Basecamp still runs on one.

In practice, a monolith is just easier to live with while the team is small. You call a function instead of standing up an API. One test suite. One deploy. And when something tips over at 2am, the stack trace points at the bug, not at a flaky network hop between two services that may not even be involved.

Where microservices earn their keep

They're not a fad. They fix a real and fairly narrow problem, and it's an org problem more often than a tech one. Several teams, each owning a service, each shipping on its own clock, nobody blocking anybody. One endpoint that has to scale hard without dragging the rest of the app with it. Netflix is the story everyone cites. A bad database failure took their monolith down in 2008, and they spent years afterward splitting into hundreds of services so one fault couldn't sink the ship.

You pay for it every single day, though. Calls that were free in memory now cross the network, so latency, retries, and half-completed requests become yours to handle. Data spreads across services, and keeping it consistent turns into its own roadmap. You need tracing, centralized logs, and an on-call crew that can follow one request as it ricochets through five or six systems at 3am.

Here's the bit people gloss over. Take on all that machinery without the tooling and the headcount to run it, and you don't get microservices. You get a distributed monolith: every cost of the network, none of the independence. That's the one outcome worth dreading.

The Amazon story everyone misquotes

You've probably seen this one passed around with a smug "microservices are dead" caption slapped on it. The real version is more interesting, and a lot more specific.

In 2023, the team running Prime Video's audio and video quality monitoring wrote up how they rebuilt it. They'd gone serverless, on AWS Step Functions and Lambda, with video frames handed between steps through S3. At their scale, the orchestration overhead and those storage round-trips piled up fast. So they folded the whole thing back into a single process inside one container. Infrastructure cost fell by more than 90%, and it scaled better on top of that.

Read the small print, though. This was one internal tool, not the entire Prime Video platform, and Amazon didn't disown microservices. The real takeaway is quieter and more honest: for that particular job, the fashionable choice was simply the wrong one.

The middle ground nobody sells you

There's a third option that almost never lands in a proposal, mostly because it's hard to make sound impressive: the modular monolith. Still one app. Still one deploy. But you put firm walls between domains inside the codebase. Billing can't reach into the guts of orders. Each module has a front door and keeps everything else private.

Shopify is the obvious example. Their core is a Rails monolith running into the millions of lines, sliced into dozens of components, with an in-house tool called Packwerk that fails the build the second one module reaches into another's internals. GitHub's still a monolith. So is Gusto. All of them well beyond the size where people assume you have no choice but to break apart.

It's a good trade. You get the clean boundaries and the team sanity, and you dodge the network tax completely. And when a domain really does outgrow the monolith, carving out a module that already has firm edges is a weekend of work, not a quarter. You earn the right to split by drawing the line in code first and seeing whether it holds.

How to make the call

Skip the theory and sit with a few uncomfortable questions.

Team size first. If three people are going to own all of it, you don't have the bodies to run separate services plus the on-call rotation they drag along. Boundaries next: if the product is still shifting week to week, any line you draw now will be in the wrong place by next month, so leave it soft. Then operations, the unglamorous part. Tracing, log aggregation, automated rollbacks, a working rotation. Missing those? Microservices will bite. And scale, last. Not "we might blow up" scale, which is a daydream, but a concrete path you can point at that has to grow on its own.

If most of your answers are "not yet," there's your answer. Build the monolith, keep it modular, and look again in a year with traffic data instead of vibes.

So what do you tell the agency?

When you sit down with a full-stack development company, don't ask for "microservices" because the word feels future-proof. Tell them what the product does, who's going to maintain it, and how fast it's likely to change. Let the shape of the system fall out of those three answers.
A partner worth keeping will push back if you ask for ten services to ship a v1. That pushback is a green flag, not a difficult vendor. Ask how they'd stop a monolith from rotting into spaghetti, how they'd handle background jobs and the schema, and what specific signal would make them pull a service out later. A full-stack development company that can only sell you the buzzword, and can't walk you through the trade-offs in plain language, has told you something useful without meaning to.

The short version

Almost nothing dies because it picked the wrong deploy topology. Products die because they never shipped. Microservices are a way to scale an organization, and the day you have that problem for real, go for it. Until then? A clean monolith with solid interior walls is the cheapest, fastest thing you can put in front of real users. Build that one. Then let the traffic tell you what, if anything, is worth breaking off.