There's a pattern I've seen repeat a few times over 20 years building software systems in both startup and enterprise environments.
Most early-stage teams believe they are building a product.
In reality, they are building two things at once:
- Their actual product
- An internal platform they didn't intend to build
And the second one quietly consumes man-years of engineering time.
The hidden tax on early-stage teams
At some point, every startup hits the same phase:
- The MVP works
- The first customers arrive
- Engineering velocity starts to slow
- "Just one more service" becomes a platform discussion
And suddenly the backlog shifts.
Not because the product changed - but because the foundations underneath it needed to evolve (without the wheels falling off!).
Based on greenfield experience, I'd guesstimate that up to 60% of engineering effort can be focused on platform foundations, delivery lifecycle and operational processes, not domain features or core business differentiators.
That ratio is not unusual.
It is normal.
And it is also destructive.
The repeated mistake
Across organisations, I've seen the same systems rebuilt repeatedly:
- CI/CD pipelines
- Infrastructure-as-code structures
- Observability setups
- Security and access control patterns
- Service templates and API conventions
- Deployment and rollback strategies
Each time:
- slightly different
- slightly inconsistent
- always re-learned under pressure
- and generally whilst trying to keep production lights on
The irony is that none of these are domain-specific.
They are global engineering concerns.
Yet every team reinvents them.
Why this keeps happening
It's not incompetence.
It's timing.
Early-stage teams optimise for:
- speed
- product delivery
- survival
So they defer platform thinking until it becomes unavoidable.
At which point:
- the system is already live
- constraints are already baked in
- rewrites are expensive
So they rebuild under pressure instead of designing under intention.
The real cost
The cost isn't just engineering time.
It's:
- delayed product delivery
- inconsistent system behaviour
- increased operational risk
- premature senior hiring in platform roles
- architectural fragmentation across services (and teams)
Most importantly:
It shifts engineering from building product value to managing internal complexity.
What changes when you design it once
When these concerns are treated as a reusable foundation instead of one-off decisions:
- teams ship faster
- systems stay consistent
- operational overhead drops
- architecture stops diverging across services
- engineering focus returns to product domain logic
This is the problem I've been formalising into an opinionated bootstrap approach with Forge Platform.
It enables production-grade microservices from day one with enterprise foundations at startup speed.
Not because teams cannot build these things.
But because they keep building them repeatedly, under pressure, in slightly different ways, everywhere.
The question I keep coming back to
If every team ends up rebuilding the same foundations…
Why are we still rebuilding them every time?
If you have any questions or are interested to find out more, it would be great to hear from you in the comments or feel free to say hello.
Top comments (0)