What a Monolith Actually Is
A monolithic application is one where all code runs in the same process and is deployed as a single artifact: a single binary, a single Docker container, or a single set of files on a web server. In a typical web application monolith, the HTTP request handling, business logic, database queries, and HTML rendering or JSON serialisation all happen within the same running application. There is no network boundary between components. A function can call another function directly. A database transaction can span multiple tables and business operations without the complexity of distributed coordination. This simplicity is the monolith's core advantage. Deploying a monolith means deploying one thing. Debugging a monolith means reading logs from one application. Adding a feature to a monolith means writing code in one place without defining API contracts and managing service versions. For a team of two to ten engineers building a product that does not yet have product-market fit, this simplicity translates directly into faster iteration.
The Modular Monolith Pattern
The mistake many teams make with monoliths is building them without internal structure, what is sometimes called a big ball of mud: all code mixed together with no boundaries, where changing one thing unpredictably breaks another. The solution is the modular monolith, where the single deployable unit contains well-defined modules with clear interfaces between them. In a Next.js AI product, this might mean separate directories and modules for user management, AI orchestration, document processing, billing, and notifications. Each module exposes a typed interface to other modules. Direct database access is contained within each module. Business logic for one domain does not reach into another domain's data directly. This structure provides most of the maintainability benefits of microservices without the operational cost. If and when the product scales to the point where service extraction is justified, each module can become a service because the boundaries are already clean.
Monolith vs Microservices: The Real Trade-off
The microservices vs monolith debate is often framed as a question of which architecture is better. This is the wrong frame. The right question is which architecture is better for your current team size, operational capability, traffic levels, and time constraints. Microservices provide independent deployability, independent scaling, and team autonomy for large engineering organisations. These benefits are real but they come with significant costs: distributed tracing, service discovery, API versioning, distributed transaction management, and the operational complexity of running multiple services in production. For a team of two to eight engineers building an AI MVP, the operational costs of microservices almost always outweigh the benefits. The monolith lets you focus on the product. The decision to decompose into services should be driven by concrete operational problems, not by a desire to follow architectural fashion. Many of the most successful AI products today, including early-stage versions of products that now serve millions of users, started as monoliths.
Deploying and Scaling a Monolith
A common concern about monoliths is that they cannot scale. This is largely a myth for the traffic levels relevant to a UK AI startup at MVP and early growth stage. A well-written monolith running on a modern cloud platform can handle tens of thousands of concurrent users with horizontal scaling: running multiple instances behind a load balancer. Most UK AI startups will not reach traffic levels that require architectural decomposition before they have significant revenue and a team large enough to manage the operational complexity of microservices. On platforms like Vercel, Railway, Fly.io, or AWS App Runner, deploying a containerised monolith is a matter of minutes. Auto-scaling is handled by the platform. Zero-downtime deployments are straightforward. The operational burden that microservices impose to achieve the same deployment and scaling behaviour is simply not necessary at this scale.
When to Move Away from a Monolith
The right time to begin extracting services from a monolith is when you have concrete, current operational problems that service extraction solves. The most common triggers are: you have a component with dramatically different infrastructure requirements (GPU inference servers), you have two or more engineering teams that cannot safely modify the same codebase without constant coordination, you have a compliance requirement that mandates data isolation between components, or a specific component needs to scale to a dramatically different level than the rest of the application. Notice that none of these triggers are about traffic volume alone. A well-scaled monolith can handle substantial traffic. The triggers are about team coordination, compliance, or infrastructure heterogeneity. If you are extracting services without hitting one of these triggers, you are adding complexity without a concrete benefit.
Monoliths and UK Compliance
For UK AI products operating under UK GDPR or FCA rules, a monolith has genuine compliance advantages. A single database with comprehensive audit logging is straightforward to map in a Data Protection Impact Assessment. Data subject access requests and right to erasure requests can be handled with a single set of queries against a known schema. There is no inter-service data flow to map, no question of which service holds which data, and no distributed transaction complexity when you need to delete a user's data across all tables. For NHS Digital integration or FCA regulated products, the simplicity of the compliance surface area is a genuine practical benefit. SpeedMVPs builds GDPR-aware monoliths by default, with data minimisation, audit logging, and right to erasure built into the data model from the start.