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 infrastructure underneath it needed to evolve (without the wheels falling off!).

Anecdotally, but based on my own greenfield project experience, I estimated that ~60% of engineering effort was going into platform delivery concerns and then operational processes, not domain features and core business concern.

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.