Stop Building Microservices: A Defense of the Monolith for Indie Hackers

The Microservice Trap

We have all read the engineering blogs from Netflix, Uber, and Amazon. They explain how they decoupled their billing system from their notification system using gRPC, Kafka, and ten different Kubernetes clusters.

It sounds smart. It sounds "scalable."

So, you sit down to build your SaaS MVP. You decide to create a separate API for authentication, a separate service for billing, and a separate frontend.

You have just signed your project's death warrant.

For a solo developer - or even a small team - Microservices do not solve complexity. They multiply it. Here is why the "Majestic Monolith" is still the superior architecture for 99% of projects in 2026.

The Hidden Cost: Context Switching

The most expensive resource a developer has is not RAM or CPU - it is Working Memory.

In a Monolith, if you want to trace a bug from the Controller to the Model to the Database, you simply Command+Click (Go to Definition). You hold the entire request lifecycle in your head because it lives in one window.

In a Microservice architecture, that same bug requires:

1. Checking the API Gateway logs.
2. Opening the Auth Service repo.
3. Realizing the error is actually in the Billing Service.
4. Opening the Billing Service repo.
5. Trying to reproduce the state across three different local servers.

You aren't coding anymore. You are playing DevOps Traffic Controller. This context switching destroys "flow state," and flow state is the only way a solo developer competes with large teams.

The Network Call vs. The Function Call

In a Monolith, if User needs to talk to Subscription, it is a method call.

• Speed: Nanoseconds.
• Reliability: 100%.

In Microservices, that is a network request.

• Speed: Milliseconds (or worse).
• Reliability: "Usually works, unless there's a timeout, or the service is restarting, or JSON serialization failed."

Furthermore, you lose ACID Transactions. In Rails, you can wrap a User creation and a Billing record creation in a transaction. If one fails, both roll back. In Microservices, you have to implement complex "Saga Patterns" to undo partial writes. That is wasted engineering time.

"But Monoliths turn into Spaghetti Code!"

This is the main counter-argument. And it’s true - if you are undisciplined.
But splitting a bad codebase into services doesn't fix the code; it just creates a Distributed Ball of Mud.

You don't need Microservices to organize code. You need Boundaries. Here is how to scale a Monolith without it becoming a mess.

Level 1: Better Namespacing

You don't need a new repository; you just need a new folder. Stop putting everything in app/models.
Group logic by domain:

• app/models/billing/invoice.rb
• app/models/onboarding/step.rb

Level 2: Service Objects & POROs

Keep your ActiveRecord models slim. Move business logic into Plain Old Ruby Objects. If your User model is 1,000 lines long, don't extract a service - extract a User::RegistrationHandler class.

Level 3: Rails Engines

This is the secret weapon. You can actually build "mini-apps" inside your main Rails app.

# config/routes.rb
mount Forum::Engine, at: "/forum"

The "Forum" logic is completely isolated. It has its own controllers, views, and models. It enforces strict boundaries (the Main App can't touch the Forum internals easily), but it still shares the same database and deployment process.

Level 4: Packwerk (The Shopify Way)

If you truly reach massive scale, you can use tools like Shopify’s Packwerk. It allows you to enforce privacy boundaries between modules via static analysis. It’s like having Microservices, but without the network latency.

Deployment: The Ultimate Multiplier

When you are a team of one, you want Atomic Deploys.
You push to main, and the entire application updates.

If you have 5 services, you have 5 CI pipelines. You have to worry about version compatibility. "Did I deploy the new Billing API before I deployed the Frontend that uses it?"

With the Majestic Monolith, deployment is a binary state: It works, or it doesn't.

Summary

Microservices solve organizational problems (too many developers stepping on each other's toes).
They do not solve technical problems.

If you are a solo developer, you don't have organizational problems. You have a "shipping" problem.
Embrace the Monolith. Keep your code in one place. Keep your database ACID compliant. And spend your time building features, not managing HTTP contracts between your own servers.

---

Is your Monolith majestic or a mess? Tell me how you organize your code in the comments! 👇