Every few months a business owner asks me whether they should "move to microservices" because a competitor mentioned it, or because a consultant pitched it as the modern way to build software. The monolith vs microservices debate has real substance behind it, but almost none of that substance is about which one is technically superior. It is about organizational scaling, and most SMEs are optimizing for a problem they do not yet have.
I have built and maintained both, across teams ranging from three engineers to twenty, and I want to give you the plain-language version of this decision, the one that skips the architecture-conference jargon and gets to what actually matters for your business.
What Each One Actually Is
A monolith is one application, one codebase, one deployment. Your inventory logic, your customer accounts, your payment processing, your reporting, all live in the same system and get deployed together. When you fix a bug or add a feature, you ship the whole application, even if you only changed one small part.
Microservices split that same functionality into separate, independently deployable services. Inventory is its own service, payments are their own service, each with its own codebase, its own database in the strict version of the pattern, and its own deployment pipeline. They talk to each other over the network instead of calling each other directly in code.
Neither one is "more advanced." Microservices are a response to a specific pain: large engineering teams stepping on each other's work inside one shared codebase. If you do not have that pain yet, adopting the pattern early means paying its costs without collecting its benefit.
The Real Trigger Is Team Size, Not Ambition
Here is the honest scaling trigger, from experience, not from a textbook: microservices start paying for themselves when you have enough engineers that a single shared codebase becomes a coordination bottleneck, typically somewhere north of 15 to 20 engineers working on the same product, organized into multiple independent teams that would otherwise be blocking each other's deploys daily.
Below that size, splitting your system into services mostly adds overhead: more infrastructure to manage, more network calls that can fail, more places for a bug to hide across service boundaries, and a meaningfully steeper hiring bar, because you now need engineers comfortable with distributed systems debugging, not just application code.
I have seen a five-person engineering team adopt microservices because it looked more "enterprise," and then spend a disproportionate share of their week debugging why Service A couldn't reach Service B, time that should have gone into shipping features. The architecture was solving a team-coordination problem they did not have, at the cost of a reliability problem they created for themselves.
When a Clean Monolith Is Simply Cheaper
For the overwhelming majority of Indonesian SMEs and mid-size companies I work with, a well-built monolith is the right call, and it is not a compromise, it is the objectively better cost structure at that scale.
Reasons a monolith wins for smaller teams:
- Cheaper to build. One codebase, one deployment pipeline, one set of infrastructure to provision and monitor. You are not paying for container orchestration, service discovery, and distributed tracing before you need any of it.
- Cheaper to run. Fewer moving parts means fewer servers, fewer monitoring dashboards, fewer places a 2 a.m. outage can originate from. A finance company client of mine cut infrastructure costs by roughly 40 percent after consolidating an over-eager microservices setup back into three well-organized modules within a monolith.
- Cheaper to hire for. Finding engineers who can be productive in a well-structured monolith on day one is easier and cheaper than finding engineers experienced in distributed systems, message queues, and service mesh tooling. In the Indonesian market specifically, that talent pool is thinner and costs more.
- Faster to reason about. When something breaks, an engineer can trace the bug through one codebase instead of hopping across service boundaries and log aggregators trying to reconstruct what happened across five different systems.
None of this means write sloppy code. A monolith built with clear internal module boundaries, the kind where inventory logic, payment logic, and reporting logic are cleanly separated in code even though they deploy together, gives you almost all of the organizational clarity of microservices without the operational cost. This is often called a "modular monolith," and it is the sweet spot for most growth-stage companies. If your system's current pain feels more like tangled code than team coordination, the fix is usually refactoring toward modularity, not splitting into services.
The Honest Triggers for Splitting
Split into microservices when you can point to a specific, current pain, not a hypothetical future one:
| Trigger | What it looks like in practice |
|---|---|
| Team coordination bottleneck | Multiple independent teams routinely blocked by each other's deploys in the same codebase |
| Genuinely independent scaling needs | One component (e.g. a notification service) needs to scale to 100x traffic while the rest of the system does not |
| Different technology requirements | A specific component genuinely needs a different language or runtime the rest of your stack can't provide |
| Regulatory or security isolation | A component must be isolated for compliance reasons, independent of team size |
Notice "it's the modern way to build software" and "our competitor does it" are not on that list. Those are fashion, not triggers, and following fashion into a distributed system you do not yet need is one of the more expensive mistakes I see growing companies make.
The Takeaway
For nearly every SME and growth-stage company, a clean, well-modularized monolith is cheaper to build, run, and hire for than a microservices architecture, and it will serve you well past the point most owners expect. Split into services only when you can point to a specific team-coordination or independent-scaling pain you are living with today, not a scale you might reach someday. If you are unsure which side of that line your business sits on, that is a conversation worth having with a partner before committing engineering months to a rebuild you may not need.