Daily-It

Why Modular Monoliths Make Sense Again for Solo Developers Working with AI

Summary. Microservices are powerful when independent teams, deployment, and scaling are truly needed. But for a solo developer or a small team working heavily with AI assistants, a Modular Monolith often gives a better cost-benefit ratio: one deployment unit, clearer module boundaries, easier local testing, and less operational overhead.

Table of Contents

  1. Why modular monoliths are back
  2. Monolith vs Modular Monolith vs Microservices
  3. Comparison table
  4. Solo development with AI
  5. Design points
  6. Common misunderstandings
  7. When to move to Microservices
  8. Conclusion
  9. References

Why modular monoliths are back

For years, many teams treated Microservices/MSA as the natural destination once a product started to grow. Independent deployment, independent scaling, and team ownership all sound attractive. But architecture is not just a code structure. It is also an operational model.

Today, more developers are building products as individuals or small teams, often with AI coding assistants. In that environment, Microservices can add overhead before the benefits appear: multiple repositories, deployment pipelines, logs, dashboards, network failures, service contracts, and data consistency problems.

A Modular Monolith keeps a single deployment unit but divides the internal codebase into explicit business modules. It keeps operations simple while preventing the codebase from turning into a Big Ball of Mud.

Monolith vs Modular Monolith vs Microservices

Monolith

A monolith is usually deployed as one unit. It is simple to run, test, debug, and deploy, especially at the beginning. The risk is that, as the system grows, boundaries disappear and changes become scary.

Modular Monolith

A Modular Monolith is still one deployable application, but internally separated by modules or bounded contexts. Membership, ordering, payment, settlement, and notification can be separate modules with explicit interfaces. The important point is not the folder structure, but the dependency rules.

Microservices / MSA

Microservices split the application into independently deployable services organized around business capabilities. This can work very well for autonomous teams and uneven scaling needs, but it requires strong DevOps, monitoring, deployment automation, and distributed-systems discipline.

Comparison table

Type Monolith Modular Monolith Microservices/MSA
Deployment One unit One unit Many services
Internal boundary Often weak over time Explicit modules/bounded contexts Network/service boundary
Operations Simple Simple to moderate Complex
Scaling Whole app Whole app Per service
Best fit MVP, small tools Solo + AI, small teams, evolving domains Multiple teams, mature platform, clear boundaries

Solo development with AI

AI assistants work within a limited context window. If a product is split across many services, repositories, deployment rules, and data stores, both the developer and the AI need to carry more context. A Modular Monolith lets you say, “Work only inside the payment module,” while still keeping the whole system easy to run locally.

That does not mean AI always requires a Modular Monolith. It means that for solo developers and small teams, explicit module boundaries without distributed operational overhead are often a practical sweet spot.

Design points

  • Split modules by business capability, not only by technical layers.
  • Prevent direct access to another module’s internals.
  • Define table ownership even if the database is shared at first.
  • Use module-level tests so AI-driven changes remain safe.

Common misunderstandings

A Modular Monolith is not just folders

If every module imports every other module’s internals, it is just a monolith with folders.

MSA is operational separation, not just code separation

Once services communicate over the network, you must deal with latency, retries, monitoring, deployment order, and consistency.

You do not need perfect boundaries on day one

Domains change. A Modular Monolith lets you adjust boundaries before turning them into hard network contracts.

When to move to Microservices

Move a module out only when the benefits exceed the cost: independent scaling, release conflicts between teams, required fault isolation, stable service contracts, and mature observability/deployment practices.

Conclusion

For a solo developer working with AI, I would usually start with a Modular Monolith rather than Microservices. This is not just a theoretical preference. After spending a lot of tokens working with tools like Claude Code, Codex, and Gemini on MSA-style systems, I started to feel a very practical wall.

At first, it feels like AI should make Microservices easier. You split responsibilities by service, ask the AI to work on each codebase, and expect the system to stay cleaner. In practice, the context gets scattered very quickly. You need to keep explaining API contracts, database ownership, message names, environment variables, authentication flow, deployment rules, and logs across multiple services. The human gets tired, and the AI misses details.

For a solo operator, the cost is often not writing the code. The real cost is continuously remembering and aligning all the separated pieces. A change in one service requires checking another service’s contract. Reproducing the full flow locally means running several processes and dependencies. Even when the AI produces a reasonable change inside one repository, subtle mismatches can appear at the integration boundary. After spending many tokens, the final integration burden still comes back to the developer.

That is why I settled on the Modular Monolith approach. Keep operations simple, but enforce module boundaries in code. You can tell the AI, “stay inside the order module,” or “do not change the public interface of the payment module.” Local execution and testing remain simple, and only when independent deployment or scaling becomes truly necessary do you extract a module into a separate service. For my use case, this is a structure that lets a solo developer and AI assistants last longer together.

What do you think? In the AI-assisted development era, should small teams still start with Microservices, or is a Modular Monolith the more realistic default?

References

  1. Microsoft Learn — Common web application architectures: https://learn.microsoft.com/en-us/dotnet/architecture/modern-web-apps-azure/common-web-application-architectures
  2. AWS — What are Microservices?: https://aws.amazon.com/microservices/
  3. Martin Fowler / James Lewis — Microservices: https://martinfowler.com/articles/microservices.html
  4. Martin Fowler — Monolith First: https://martinfowler.com/bliki/MonolithFirst.html
  5. Martin Fowler — Microservice Prerequisites: https://martinfowler.com/bliki/MicroservicePrerequisites.html
  6. Spring Modulith Reference: https://docs.spring.io/spring-modulith/reference/
  7. microservices.io — Monolithic Architecture: https://microservices.io/patterns/monolithic.html
  8. microservices.io — Microservice Architecture: https://microservices.io/patterns/microservices.html
  9. Kamil Grzybek — Modular Monolith: A Primer: https://www.kamilgrzybek.com/blog/posts/modular-monolith-primer
  10. Anthropic Docs — Context windows: https://docs.anthropic.com/en/docs/build-with-claude/context-windows.md