We celebrate the launch. We ignore the next ten years.
In software, we’ve got names for the phases. Day 0 is planning and design. Day 1 is build and deploy. Day 2 is everything that comes after — operations, maintenance, optimisation. The boring stuff. The expensive stuff. The stuff that actually decides whether your product survives.
Across the teams I’ve led — at VeriPark, Booking, and now TomTom — the time split has been remarkably consistent:
10–15% on Day 0. 20–30% on Day 1. 60–70% on Day 2.
Sixty to seventy percent. The biggest slice of engineering effort in the industry, and somehow the one we talk about least. Because Day 0 is exciting. Day 1 is a launch party. Day 2 is Tuesday at 2pm with a pager and a runbook.
This is where Platform Engineering earns its keep. Not as a tooling choice. As a leadership philosophy.
The principle I keep coming back to is shift down — not to be confused with shift left.
Shift left pulls work earlier in the cycle. It still sits with the developer. Shift down pushes work below the developer — into a platform layer that handles security, compliance, observability, scaling, and cost control by default.
When you get this right, three things happen:
- Developers reclaim cognitive load. They’re building, not firefighting.
- Standards hold across hundreds of services without anyone policing them.
- Day 2 stops being a tax. It becomes a feature of the platform itself.
And we’re about to need this more than ever.
AI is multiplying how much we can build. That’s the good news. The quiet news is that every AI-generated service still has to be monitored, patched, scaled, and paid for. More Day 1 velocity, without a stronger platform layer, just means a bigger Day 2 bill — with compounding interest.
The orgs that treat their platform as a product, not an afterthought, will absorb the AI wave. The ones that don’t will drown in their own velocity.
Build fast. But shift down first.