Stop Starting with Microservices: Why I Built a Modular Monolith for my B2B SaaS Boilerplate

Mahmoud Farouk — Sun, 12 Apr 2026 22:46:28 +0000

If you've ever started a new B2B SaaS project, you know the drill. Before you write a single line of feature code that actually brings value to your users, you spend weeks (or months) wrestling with the exact same infrastructure:

Setting up Multi-tenancy (and worrying about data leakage).

Configuring stateless JWT authentication.

Handling database migrations.

Integrating payment webhooks safely (idempotency, anyone?).

As a Principal Software Developer, I realized this "setup fatigue" was killing momentum. So, I decided to build the ultimate boilerplate to solve this once and for all: the Arab Enterprise Kit (AEK).

But when it came to the architecture, I made a controversial choice for 2026: I completely ignored Microservices.

Here is why I went with a strict Modular Monolith instead, and how I structured the tech stack.

The Microservices Trap for Early-Stage SaaS
Microservices are fantastic for scaling massive engineering teams. But for solo founders or small teams launching a B2B SaaS, they introduce a DevOps nightmare:

Distributed tracing becomes mandatory.

Data consistency and distributed transactions (Saga patterns) slow down feature delivery.

Infrastructure costs spike before you even have your first paying customer.

The Modular Monolith Solution
Instead of splitting by network boundaries, I split by logical boundaries within the same deployment unit.

Here is the tech stack I chose for the AEK:

Backend: Java 25 & Spring Boot 4. We use Single-Schema Multi-Tenancy with Hibernate Filters. It ensures strict data isolation at the ORM level without the overhead of spinning up a new database per tenant.

Frontend: Angular 21 (Zoneless UI using Signals). Combined with native Tailwind RTL/LTR support, making it perfectly suited for global and MENA region applications.

Integrations: * Stripe Webhooks: Fully configured with idempotency keys to prevent double-charging during network retries.

Local AI (Ollama): Because B2B enterprise clients care deeply about privacy, sending data to 3rd party LLMs is often a dealbreaker. Integrating local AI ensures zero data leaks.

The Result?
By keeping everything in a well-structured monolith, you get the deployment simplicity of a single .jar file, but the clean separation of domains. If one module ever needs to scale independently, extracting it is straightforward because the boundaries are already respected in the code.

🎁 Get the Full 37-Page Architectural Blueprint
Before I even wrote the code for the AEK, I documented every single architectural decision, tradeoff, and pattern into a comprehensive blueprint.

If you are a technical founder or developer struggling with the initial architecture of your SaaS, you can grab the complete 37-page Architectural Blueprint for free here:

👉 https://mahmoudfarouk28.gumroad.com/l/sdmeap

I'd love to hear your thoughts. Have you fallen into the microservices trap early on, or are you team a monolith? Let's discuss in the comments! 👇

DEV Community: Mahmoud Farouk

Stop Starting with Microservices: Why I Built a Modular Monolith for my B2B SaaS Boilerplate