When Not to Reach for Microservices: A Startup's First 18 Months

Microservices let independent teams deploy independently. That is the whole point. Team A ships the billing service on Tuesday without coordinating with Team B, who owns search. Separate repos, separate pipelines, separate on-call rotations. No shared release train, no blocking on each other.

Now count your teams. You have one. Maybe two engineers who sit next to each other.

When one team owns every service, you get the costs of independent deployment with none of the benefits. You coordinate every change anyway, because you are the same people. You just added network calls between functions that used to be method calls.

Fowler himself wrote a follow-up, : they moved a monitoring tool from a distributed serverless architecture back to a monolith and cut infrastructure cost by 90 percent. The direction of that migration is the point. Even inside a company that runs microservices at planet scale, the right call for a specific workload was to collapse it back.

You keep the option to split open by building the monolith well, not by splitting early. Use modules with clear interfaces. Keep your domain logic out of your web framework. A well-structured monolith is a microservice architecture that hasn't been forced apart yet.

src/

  billing/      # clear public interface, owns its tables

  orders/       # talks to billing through a function call

  users/        # for now

  web/          # http handlers, thin

Each top-level package is a future service if it ever needs to be. The boundaries live in code, enforced by review and imports, not by the network. That costs you nothing today and saves you the rewrite-the-seams pain later.

The signals that say it's time to split

Don't split because traffic grew. A bigger Hetzner box, a read replica, and a cache handle far more load than most startups ever see. Vertical scaling buys you a long runway, and it is boring in the good way.

Split when you hit one of these, and not before:

• 
  Team friction is real and measurable. Two or more teams keep blocking each other on a shared deploy. People are waiting on a release train. That is the Conway's Law signal, and it is the only one that actually justifies the cost.


• 
  One component has a genuinely different scaling profile. A video transcoder, an ML inference path, or a job runner that needs GPUs or 10x the memory of everything else. Isolating that workload is a real win because it scales on a different axis.


• 
  A clear blast-radius boundary matters. A piece of the system whose failure must never take down checkout, where the isolation is worth the operational cost.


• 
  You need different runtimes. One part is Python for the ML libraries, the rest is Go. A process boundary is the honest way to draw that line.

Notice what is not on the list: "we might scale," "it's cleaner," "the architecture blog said so," or "investors will ask." Those are reasons to write a better monolith, not to distribute one.

What to do in the first 18 months

Build a monolith. One deployable, one database, modules with sharp internal boundaries. Put it on a single server you understand. Add a read replica and a cache before you add a service. Keep your domain logic framework-agnostic so the seams are visible when you do need them.

Spend the time you save on the thing that actually kills startups, which is not having a product anyone wants. The distributed-systems tax is real money and real hours, and before product-market fit you cannot afford either. Pay it when an org problem forces your hand, with production traffic telling you exactly where the lines go.

The companies you admire that run hundreds of services almost all started with one. They earned the complexity. You get to skip it until you have.

If this matched how you think about early infrastructure, the same reasoning runs through Ship It — the book works through hosting, databases, and architecture decisions at each budget and stage, with the same "what to pick and when to upgrade" framing. It is the longer version of this post: choosing complexity on purpose instead of by default.