AI Startup Architecture and Microservices

A founder asked me to design their AI product on microservices. I told them no.

Not because microservices are bad. Because they were a two-person team with six months of runway, building something that didn’t exist yet. Microservices would have meant spending half that runway on infrastructure plumbing before a single user touched the product.

The pitch sounded reasonable on paper. Their previous technical advisor had drawn up an architecture with separate services for AI orchestration, user management, content delivery, and billing. Clean boxes on a whiteboard. In practice, it meant four deployment pipelines, a service mesh, distributed tracing, and an entire DevOps discipline they had no one to run.

We went with a modular monolith instead. One deployable unit, but with strict boundaries between modules internally. Each module owned its own database schema, its own contracts, and its own logic. The seams were real. They just weren’t network calls yet.

Six months later, they had a working product, paying users, and a codebase that was structured well enough that when they eventually needed to extract a service, they could do it along a boundary that already existed. No rewrite. No drama. Just a deliberate decision made at the right time instead of the wrong one.

The takeaway for founders: the most complex architecture is rarely the right architecture for your stage. You don’t need the system your product might need in two years. You need the one that gets you to revenue with the least wasted runway. A good technical partner will push back when the impressive-sounding option is also the expensive one.

What’s one architecture decision you wish you’d made simpler from the start?