Every few months, a founder tells us usually with a hint of apology that their last team convinced them to start with microservices. Six months later they have twelve repositories, a service mesh nobody fully understands, and a feature backlog that hasn't moved in weeks. The team spends more time debugging cross-service network calls than building the product.
This isn't a story about microservices being bad. It's a story about sequencing. Microservices solve organisational and scaling problems that most early-stage products don't have yet and the tax you pay for that architecture shows up immediately, while the benefits only show up once you actually have the scale problems it was designed for.
The hidden cost nobody puts in the estimate
A monolith deployed as a single service has one build pipeline, one log stream, one database transaction boundary, and one place to set a breakpoint. A microservices architecture even a modest one with four or five services multiplies almost every operational concern: service discovery, distributed tracing, network retries, data consistency across service boundaries, and versioned API contracts between teams that, in a five-person startup, are often the same two people talking to themselves through an HTTP call.
None of this is free. We've seen early-stage teams spend 30-40% of their sprint capacity on infrastructure plumbing that a monolith would have made unnecessary time that should have gone toward validating whether anyone wants the product in the first place.
The question isn't "will we eventually need microservices?" Most successful products do, eventually. The question is whether you need them on day one, when the cost of being wrong about your domain boundaries is highest and your appetite for operational complexity is lowest.
What we recommend instead
For the large majority of new products, we start with what's sometimes called a "modular monolith" a single deployable service, but with clear internal module boundaries that mirror how you'd eventually want to split services if and when that becomes necessary. This gets you most of the organisational clarity of microservices without the distributed-systems tax.
- One codebase, one deploy pipeline, one place to debug an issue end-to-end.
- Clear internal module boundaries enforced through code structure and interfaces, not network calls.
- A single database to start, with schemas organised by module so a future split is straightforward.
- Feature flags to decouple deploy from release, giving you microservice-style independent shipping without the infrastructure.
The signals that tell you it's actually time
We don't treat "never split the monolith" as a rule either that's just as dogmatic as splitting on day one. There are concrete signals that tell you the trade-off has flipped:
1. Team boundaries are causing deployment conflicts
When two teams are regularly blocked on each other's release schedule because they share a single deployable, that's a strong signal one module deserves its own service and its own release cadence.
2. One module has fundamentally different scaling needs
If your image-processing pipeline needs to scale independently of your user-facing API different hardware, different scaling triggers, different failure tolerance that's a legitimate reason to extract it, even early.
3. You have real, sustained traffic patterns to design around
Splitting a service based on guessed future load is expensive guesswork. Splitting based on twelve months of real production metrics is an engineering decision with actual data behind it.
What this looked like for PayStream
Our fintech client PayStream is a good example of doing this in sequence rather than upfront. We shipped their MVP as a modular monolith in eleven weeks. Eighteen months and 2 million monthly transactions later, we extracted exactly one service the fraud-scoring engine because it needed independent scaling and a separate on-call rotation from the rest of the platform. Everything else has stayed in the monolith, and it still deploys in under four minutes.
The takeaway
Architecture decisions are sequencing decisions as much as they are technical ones. The right question at the start of a project usually isn't "monolith or microservices" it's "what's the smallest architecture that lets us learn what we need to learn this quarter, without making next year's decisions harder than they need to be." For almost every early-stage product we've worked on, that answer has been a well-organised monolith, not a service mesh.
Bilal Ahmed
Head of Engineering at Neurals Solutions. Previously built distributed systems for a regional fintech before co-leading delivery here.
