Microservices Are Not a Starting Point. They Are a Destination.
I am going to say something that might get me ratio'd on Tech Twitter.
Most startups do not need microservices. Not right now. Maybe not for years.
I say this as someone who built one anyway.
VerifiedCore — a virtual number verification platform I founded and engineered solo — runs on 14 Spring Boot 3 services. Auth, wallet, payments, notifications, delivery, analytics, eSIM, call plans, reseller, number management, and more. Kafka for async events. gRPC for synchronous calls between services. Separate MongoDB databases per service. An API gateway in front of everything.
It is a genuinely complex system. And if I were starting over today, I would not build it this way. Not yet.
We Learned the Wrong Lesson From Netflix
The microservices movement was popularised by Netflix, Amazon, and Google. The argument made sense for them: massive engineering organisations, thousands of engineers stepping on each other's code, services that need to scale independently to handle hundreds of millions of users.
What the industry did with that lesson was cargo-cult it.
Developers read the Netflix case study and started splitting their todo-list app into a task-service, a user-service, and a notification-service before they had a single paying customer. Teams of three engineers started debating service mesh configurations and distributed tracing tooling before they had shipped anything worth tracing.
The architecture that solved Netflix's problems at 200 million users became the default starting point for teams building for 200 users. That is not how engineering decisions are supposed to work.
The Tax Is Real and Nobody Advertises It
When you adopt microservices early, you do not just adopt the benefits. You adopt the full infrastructure bill upfront, before you have the scale to justify it.
In my case, that bill looked like this:
Every service needs its own Dockerfile, its own health check, its own database migration tooling, its own Kafka consumer group, its own Redis configuration, and its own Spring Security config. Miss one — as I did with the payment service — and an entire feature silently breaks in production. Not with an error you can easily trace. With a 401 on every webhook that a payment provider sends you, meaning no payment ever completes, and you only find it by manually exercising the live flow weeks later.
With 14 services, there are 14 surfaces where that kind of gap can hide.
Local development became its own full-time job. My development machine could not start all 14 services simultaneously without Docker Desktop running out of memory. I had a documented procedure for starting services one at a time, waiting for each to report healthy before starting the next. JVM startup on a constrained host took anywhere from 8 to 15 minutes per service. A single rebuild could take long enough to make coffee, come back, and find it had failed silently mid-build.
This is not a complaint. It is the real cost of the architecture. And at the stage I was at — a solo founder still discovering what the product needed to be — I was paying that cost with time I should have been spending on the product itself.
"But What About Scaling?"
This is the most common objection I hear when I make this argument, so let me address it directly.
Your startup is almost certainly not at the scale where microservices provide a meaningful scaling advantage. If you are, you will know it — because you will have real traffic data telling you which specific service is the bottleneck. You will not be guessing.
The argument "we might need to scale this part independently someday" is not an engineering decision. It is anxiety dressed up as architecture.
A well-structured modular monolith — one where domain boundaries are clear and enforced inside the codebase — can be extracted into services later, when you have evidence that a specific module needs independent scaling. Shopify ran on a Rails monolith for years while handling billions in transactions. Stack Overflow serves millions of developers on a monolith that most engineers would call embarrassingly simple. Simple systems are debuggable. Debuggable systems ship.
Extracting a service from a modular monolith is hard work. It is not insurmountable. Starting with 14 services before you understand your domain is harder — because you are locking in service boundaries before you know where the real seams are. I have refactored within a monolith. I have also renegotiated a gRPC contract across a service boundary. They are not the same category of effort.
When Microservices Are Actually the Right Answer
I want to be precise here, because this is not a binary argument.
Microservices make sense when team size creates real coordination friction. When you have enough engineers that deploying one module requires synchronising with three other teams, service independence pays for itself. This is Conway's Law in action — your system architecture will mirror your communication structure. If your communication structure is two people talking across a desk, your architecture should reflect that.
They make sense when you have measured a bottleneck that genuinely requires independent scaling. Not assumed one. Measured one.
They make sense when different parts of the system have such different operational profiles — uptime requirements, latency tolerances, deployment cadences — that a monolith's shared fate becomes an actual liability rather than a theoretical one.
None of those are circumstances that describe a startup in its first year. Maybe not in its second.
What I Would Tell Myself Before I Started
Build one service. Call it backend. Give it clean internal package structure — user, wallet, payment, notification — with strict rules about what can call what. Write it the same way you would write the microservices version, except everything runs in one process.
You will ship faster. You will find bugs faster. Your local development setup will be a single docker compose up. When you eventually outgrow it, you will know exactly where to make the first cut — because your traffic data and your team structure will tell you, instead of your imagination.
The goal of architecture is not to build the system that could theoretically handle your best-case future. It is to build the system that ships your product today while leaving the right doors open for tomorrow.
Microservices are a destination. A modular monolith is how you earn the right to need them.
I build backend infrastructure and mobile products. Currently working on VerifiedCore — a virtual number verification API for developers. If this resonated, I write more pieces like this alongside technical deep-dives on Java Spring Boot and Flutter.