Your Developer Wants Microservices. You’re the One Paying for It.

Somewhere in the last month, your lead developer told you the app needs to be split into microservices. He believes it. He had slides, or at least a whiteboard. You understood maybe half of what he said, and now the decision is sitting with you, because you’re the one who pays for it.

I want to give you the answer I’d give you if we were on a call: no, almost certainly not. Not at your stage, not with your team size, and not for the reasons you were given. In twenty years of building systems, including ones that handled over three million requests a day, I have never seen a startup fail because it kept its code in one application. I have watched several grind to a halt because they split it apart too early.

Your developer isn’t lying to you, and he isn’t incompetent. He’s feeling a real pain and reaching for the most famous cure. My job in this article is to show you what the pain actually is, what the cure actually costs, and the cheaper prescription I give in almost every case: a modular monolith, which is one application with disciplined boundaries inside it.

What microservices are, in words you can repeat in a meeting

Right now your product is one program. Everything lives together and deploys together, and when the billing code needs a user’s email address, it just asks. There’s a name for this: a monolith. Developers say the word like it’s a diagnosis. It isn’t. Most of the successful software you use every day is a monolith, and the companies running them are not embarrassed about it.

Microservices means cutting that one program into several smaller programs. Billing runs on its own, notifications run on their own, search runs on its own, and instead of asking each other directly, they make requests over the network, the same way your browser talks to a website.

That one change is the entire decision, so sit with it for a second. A request inside one program cannot fail. A request over a network can. It can be slow, it can time out, it can arrive while the other service is mid-deploy and get no answer at all. Every one of those failure cases becomes code your team writes, tests, and maintains forever. You are not buying a cleaner system. You are buying a distributed system, and distributed systems are a specialty, not a default.

The problem microservices were built to solve, and why you don’t have it

Microservices exist because of headcount, not traffic.

Put sixty engineers in one codebase and they trip over each other constantly. Merge conflicts eat mornings. One team’s broken build blocks everyone’s release. Your two-line fix waits behind a risky change from a team you’ve never met. Splitting the system lets each team own their piece and ship on their own schedule. That’s the win, and at that scale it’s a real one.

I lived this. I was technical lead on a product doing 3M+ requests a day, and I later led its migration to containers on AWS. The service boundaries that worked were the ones that matched how the teams were already organized. The ones that failed were drawn because the architecture diagram looked better with more boxes. The system didn’t care about the diagram. The people did.

Now count your engineers. If the answer is two, or four, you do not have a coordination problem. You have people who talk to each other at lunch. Adding network boundaries between them doesn’t remove friction; it invents friction that wasn’t there. And on the traffic side, a competently built single application on modern cloud infrastructure will carry more load than almost any startup ever sees. When it needs to carry more, you run additional copies of it. That’s a configuration change, not a rebuild.

What the migration actually costs

The estimate you’ll be shown covers the code. Almost nothing else that matters is in it.

Start with visibility. In one program, when something breaks, you get a stack trace pointing at the exact line. When a request dies somewhere between service three and service four, you get silence, unless every hop was instrumented in advance. The tool for that is OpenTelemetry, and in a distributed system it is mandatory, not nice-to-have. I led an enterprise platform through that migration. It worked; our detection and recovery times dropped by roughly half. It also took months of dedicated effort, and that was with an experienced team. Your two developers would be doing it on nights and weekends between feature requests.

Then multiply your pipelines. One application means one build, one test suite, one deploy. Nine services means nine of everything, plus tooling to keep versions compatible, plus a way for a developer to run the whole constellation on a laptop. None of that ships a feature.

Then there’s your data. Today, when a customer subscribes, recording the subscription and charging the card happen together or not at all, because the database enforces it. Split billing from subscriptions and that guarantee evaporates. Your team now hand-writes the logic for every half-finished state, and every founder I know who’s been through this has the same war story: a customer charged for a thing the system swears they don’t have.

And someone carries the pager for all of it. More pieces, more 2am failure modes, same three people.

I’m not telling you microservices are bad. I’ve built them and I’d build them again. I’m telling you the price tag, because the person proposing this to you probably didn’t.

The cheaper cure: a modular monolith

Here’s what I think your developer is actually feeling. He changed the pricing logic and the signup flow broke, and he can’t explain why. Or nobody remembers which of three places the discount rules live. That pain is real. It’s a boundary problem, and services are one way to force boundaries. They’re just the most expensive way ever invented.

A modular monolith gets you the discipline without the distributed system. One application, one deploy, but inside it the code is divided into modules with rules that are actually enforced: billing has a front door, and no other module gets to reach around it into billing’s tables. The thinking comes from Domain-Driven Design, which calls these divisions bounded contexts. Strip the vocabulary away and it means each part of your business owns its own words and its own data.

I made exactly this call on a recent AI SaaS product I architected. Two of us building it, customers waiting, and a business plan that needed the product to expand into new verticals later. Going to services first would have burned two months on plumbing. Instead we built a modular monolith with clean seams, designed multi-tenancy in from day one so new verticals wouldn’t require a rewrite, and kept one-page architecture decision records so future-us could see why past-us did anything. Yes, a decision log on a two-person team. It takes twenty minutes per decision and it has already paid for itself.

The founder-relevant part is what those seams do to your options. If the internal boundaries are honest, pulling one module out into its own service later is a week or two of work, done when the evidence says it’s time. If the boundaries were never real, the “split” your team proposes later is a rewrite wearing a nicer word. Keeping an expensive decision reversible until you know more is not indecision. It is the discipline the whole job runs on.

The four cases where I’d say yes

When a founder asks me to bless a split, I’m looking for one of these. Usually the answer is one service, not twelve.

Your engineering team outgrew the codebase. Past eight or ten engineers, coordination costs get real and you’ll hear it directly: deploys queue up, people complain about waiting on each other. Below that headcount, this reason is not available to you.

One workload has a completely different cost shape. This is the case I see most in 2026. Your core app is cheap and steady. Your AI inference endpoint is expensive, slow, and spiky. Keeping them together means provisioning everything for the worst-case workload. Carving the AI piece out so it scales and gets budgeted on its own is a legitimate, money-saving reason.

Compliance touches part of your product but not all of it. I’ve done payments work under PCI Service Provider requirements and architected a Class III medical device under FDA regulation, and in both worlds, isolating the regulated piece shrinks what the auditor examines and what the heavy rules apply to. If you take card data or health data, this boundary can be worth real money.

Something contractually ships on its own clock. A partner integration a customer requires you to release independently. Rare at your stage. It happens.

Read that list again and notice what’s missing: “we’re getting a lot of traffic” isn’t on it.

Anti-patterns to avoid

The split by technical layer. A “database service” and an “auth service” that everything else must call for every operation. Nothing can deploy independently because everything depends on the same two chokepoints, so you’ve paid full distributed-system price and received none of the independence. I see this more than any other failure, and it usually kills the project.

The AI-scaffolded architecture. Claude Code or Cursor will happily generate twelve services with Dockerfiles and tidy folder structures in an afternoon, and the pull request will look magnificent. Generating services became nearly free. Operating them didn’t. It has never been easier to create an architecture your team cannot run.

The refactor that’s secretly a rewrite. Listen for the verbs. “Extract the billing module” and “rebuild the platform as services” carry completely different risk, and I’ve sat in meetings where both were described with the same hand-waving. Make them say which one it is.

The résumé-driven decision. Distributed systems are interesting, and engineers want interesting work. I get it; I’ve felt that pull myself. But it’s your runway, and “will this be fun to build” and “does the business need this” are different questions. You’re allowed to ask the second one out loud.

How to start, gently

You don’t need to learn architecture. You need four questions and the nerve to wait for complete answers.

First: “What can we do after this that we can’t do today?” A good answer names something concrete, like the AI workload scaling separately or the payments piece getting isolated for the PCI audit. “It’s better architecture” and “we’ll need it eventually” are not answers. They’re vibes.

Second: “What does this cost to run, every month, after it ships?” Not the build estimate. Operating, monitoring, deploying, debugging. If nobody can put a number on it, the plan isn’t done being written.

Third: “Can we do the boundary without the split?” Have the team take the most tangled part of the system and clean it into a proper module inside the existing app. Two weeks, zero new infrastructure. If it goes well, you just captured most of the benefit for a fortieth of the price. If it goes badly, you learned that the team can’t draw boundaries yet, which is the single most important thing to know before letting them draw nine of them.

Fourth: “Will someone write this down?” One page. The decision, the options considered, the reasoning. That’s an architecture decision record, and it’s the cheapest insurance in software.

And if the answer at the end of all that is still yes: split one thing. Live with it for a quarter. Let production tell you whether the second split earns its place, because production is the only reviewer whose opinion counts.

The founders I’ve watched get hurt by this weren’t careless. They were sold an expensive answer by someone who sincerely believed it, in a room where nobody could price it. What’s the biggest technical decision you’ve had to approve without any way to check the math?