Technical Project Manager: Monoliths vs Microservices Architecture

When a client asks whether to build a monolith or adopt microservices, the question they're really asking is a project management one first, architecture second. The choice shapes how you staff, plan, test, and deploy — for the life of the project. Getting it wrong doesn't just add technical debt; it slows your team down in ways that are hard to recover from.

What these terms actually mean

A monolith is a single application where all the code lives together and deploys as one unit. User authentication, business logic, notifications, reporting — all in one codebase, one deployment pipeline, often one database. When you update any part of it, you redeploy the whole thing.

Microservices split that application into separate services, each responsible for one domain. Authentication is one service. Orders are another. Notifications are a third. Each has its own codebase, its own deployment pipeline, sometimes its own database. Services communicate with each other over APIs.

Neither is inherently better. They solve different problems at different scales.

How the choice changes how you plan

A monolith means one team — or multiple squads working in one shared codebase. Deployments are coordinated events. Sprint planning is simpler because dependencies are managed through code and visible in the IDE. Integration testing is relatively straightforward because all the pieces run together.

Microservices require each service to have a team with ownership, its own CI/CD pipeline, its own monitoring, and its own runbook. Your sprint planning must account for cross-service dependencies and API contracts. A change in one service can break another — which means you need contract testing, API versioning, and inter-team coordination that a monolith simply doesn't require.

When a monolith is the right choice

For most early-stage and growth-stage products, a monolith is the better starting point. If your engineering team has fewer than 20 people, the coordination overhead of microservices — separate deployments, distributed tracing, API contracts — will slow you down more than it helps.

A well-structured monolith (clear module boundaries, no cross-cutting dependencies) can handle significant scale. Companies like Stack Overflow ran on a monolith well past the point where most developers assumed they'd need to split things up. The rule is: if your team can deploy without blocking each other, you don't need microservices yet.

For Kenyan startups and growth-stage companies, a monolith also tends to be cheaper to run. You're running one set of services, one database, one set of infrastructure — not twelve.

When microservices make sense

Microservices become the right answer when:

• Different parts of your system have genuinely different scaling needs — your notification service is hit hundreds of times a second while your reporting service runs overnight
• You have multiple autonomous teams that consistently block each other in a shared codebase
• You need different services to use different technology stacks (your ML pipeline in Python, your API in Go, your frontend in TypeScript)
• You need to deploy different services at very different frequencies without coordinating with other teams

None of these conditions typically exist at the beginning of a project. They emerge as the product grows and the team scales.

The questions to ask before deciding

Before recommending an approach, get answers to these:

• How many engineers will work on this over the next 12 months?
• Are there genuinely different scaling profiles across different parts of the system?
• Does the team have experience with distributed systems — service meshes, contract testing, distributed tracing?
• Can we afford the coordination overhead at our current team size and velocity?

If the honest answer to the last question is no, start with a monolith. You can extract services later when the boundaries are clear and the team is large enough to own them. Going the other way — collapsing poorly-designed microservices into a coherent monolith — is significantly harder.

The best architecture is the one your team can actually operate and improve. Start simple, and let the structure grow with the problem.