What Microservices Architecture Actually Is
Microservices architecture is a style where an application is built as a collection of small, independently deployable services, each responsible for a specific business capability and communicating over a network (typically HTTP REST or gRPC). A theoretical e-commerce application might have separate services for user authentication, product catalogue, orders, payments, notifications, and search. Each service has its own database, can be deployed independently, and can be scaled independently. At large companies like Netflix, Amazon, and Uber, microservices enable dozens of autonomous engineering teams to ship independently without coordination bottlenecks. The key word is dozens of teams. The operational machinery required for microservices to function reliably includes service discovery, distributed tracing, inter-service authentication, circuit breakers, deployment pipelines for each service, and observability tooling that correlates logs across multiple services. None of this is free, and all of it requires engineering effort that is not building your product.
What a Monolith Architecture Actually Is
A monolith is a single deployable application that contains all of the business logic, API endpoints, database access code, and background processing. It runs as one process, deployed as one unit, with one database. The word monolith is often used pejoratively, but most successful software started as a monolith, including Shopify, GitHub, Basecamp, and many others that scaled to millions of users before extracting services. A well-structured monolith uses internal modules or packages to separate concerns: an auth module, a billing module, an AI module, a data access layer. This is sometimes called a modular monolith. The separation is logical rather than physical, which means you can eventually extract a module into a microservice when there is a specific reason to do so, without the day-one overhead of running distributed infrastructure. For an AI MVP, the monolith typically means a Next.js application with API routes, a PostgreSQL database, and any AI-specific components (vector store, LLM client, embedding service) as modules within the same codebase.
Development Velocity and Iteration Speed
This is the decisive dimension for MVP stage. With a monolith, a developer changing the relationship between two features (say, adding a notification when a user's AI-generated report is ready) makes the change in one codebase, tests it locally, and deploys it as one unit. With microservices, the same change requires modifying the notification service, modifying the report service, updating the API contract between them, deploying both services, and testing the integration. Each of these steps adds time. At MVP stage, requirements change constantly. What the user authentication flow looks like, where billing fits into the product journey, which AI features get prioritised, all of these evolve rapidly in response to user feedback. Each architectural boundary in a microservices system becomes a point of friction when requirements cross those boundaries, which in an evolving product they constantly do. The monolith removes this friction entirely during the phase when you need maximum iteration speed.
Operational Complexity and Infrastructure Cost
Running microservices requires running multiple services: multiple deployment pipelines, multiple sets of environment variables, multiple health check endpoints, multiple log streams, and multiple sets of infrastructure costs. A three-service architecture (API, background worker, AI inference) deployed on Railway might cost GBP 30-50 per month. A six-service architecture (auth service, core API, notification service, billing service, AI service, search service) on the same platform costs more and requires significantly more DevOps discipline to operate reliably. A monolith runs as a single service with one deployment pipeline. Your infrastructure cost is lower. Your deployment surface area is smaller. When something goes wrong, there are fewer places to look. For a startup where engineering time is the scarcest resource, operational simplicity is a feature. You want developers solving product problems, not debugging why service A cannot reach service B across a network boundary.
AI Workload Considerations
AI MVPs sometimes create genuine pressure toward a partial service separation, even at MVP stage. If your product runs a heavy AI pipeline (batch document processing, model fine-tuning, or long-running agent workflows), running these within the same process as your web server creates resource contention and reliability risk. A web request that shares memory with a 10-minute batch job is not a well-designed system. The pragmatic answer is not a full microservices architecture but a single service extraction: keep the main application as a monolith and extract only the long-running AI workload into a separate background worker process. This is a targeted split based on a real operational need (CPU and memory isolation) rather than an architectural philosophy. Platforms like Railway and Fly.io make running a monolith alongside one worker service straightforward. This gives you the simplicity of a monolith for 90% of your code while handling the genuine resource isolation need for AI batch workloads.
Team Size and Coordination Overhead
Microservices deliver their primary benefit when you have multiple autonomous teams who need to ship without coordinating with each other. If team A owns the payments service and team B owns the notifications service, they can deploy independently, use different technology stacks, and scale their services at different rates. At MVP stage with a team of 2-5 engineers, none of these benefits apply. Every engineer works across the whole product. Service boundaries do not reduce coordination overhead; they add it. The team building a microservices MVP spends meaningful time on inter-service contracts, versioning, and deployment coordination that contributes nothing to user-facing features. The monolith eliminates this overhead entirely. SpeedMVPs delivers MVPs with teams of 2-4 engineers working on a unified codebase. Every engineer can touch every part of the system, which is essential for the rapid changes that an MVP build requires.
When Microservices Are Justified at MVP Stage
The honest answer is rarely, but there are specific scenarios where a targeted service extraction is justified from day one. If a component of your MVP has fundamentally different runtime requirements (a Python AI inference server alongside a Node.js web API), running them as separate processes is practical and not properly called microservices. If your product has a genuine security boundary between components (a sensitive data processing service that must be isolated from the public-facing API for compliance reasons, relevant in healthtech or fintech under FCA or MHRA oversight), separation is warranted. If you are building on top of an existing system and need to integrate with it over HTTP, that is not a microservices decision, it is an integration architecture. These targeted separations are different from a full microservices strategy and do not carry the same overhead.
Verdict
Start every MVP as a monolith. This is not a conservative opinion; it is what the evidence from successful software projects consistently shows. Shopify, GitHub, and Stack Overflow all scaled to millions of users on monolithic architectures before selectively extracting services for specific scaling or team autonomy needs. At MVP stage, the primary risk is not that your architecture cannot scale: it is that you run out of runway before finding product-market fit. The monolith maximises your iteration speed and minimises operational complexity during the phase when speed matters most. Extract a service when you have a specific, concrete reason (language mismatch, resource isolation need, team autonomy at scale) not because microservices sound more sophisticated. SpeedMVPs builds every AI MVP as a well-structured monolith with clear internal module boundaries that make future service extraction straightforward when and if the time comes.