Somewhere in most engineering organisations of any size there is a team building a thing with a name like Foundry or Compass or Runway. It provisions environments, wires up deployment, standardises logging, and gives product engineers a path to production that does not require them to hold the whole cloud in their heads.
Nearly every one of these is built independently, they solve substantially the same problem, and none will ever be seen by a customer. Whether that is a waste depends on a question most organisations have not asked out loud.
The complexity is real and it has to live somewhere
The case for building one is not empire-building. Deploying a service properly now involves networking, identity, secrets, observability, cost controls and a compliance posture, and expecting every product team to carry that competence produces either paralysis or a series of quietly non-compliant systems.
A platform team absorbs it once. Product engineers get a narrow path that works, the organisation gets consistency it can audit, and the specialised knowledge sits with people who maintain it deliberately rather than being rediscovered by whoever last read the documentation.
Where these go wrong is predictable and it is rarely technical. The platform becomes a bottleneck, because every team needing something slightly unusual has to queue behind whoever maintains the abstraction. It becomes stale, because the underlying services move faster than the wrapper. And it acquires the property that makes internal software genuinely dangerous — nobody outside the company can be hired who already knows it, and the people who wrote it eventually leave.
That last point is what turns a platform into the trillion-dollar rewrite nobody can postpone on a fifteen-year delay. Bespoke internal tooling ages exactly like any other legacy system, with the added difficulty that its documentation was always going to be written next quarter.
The organisations getting the most from this have generally been strict about one thing: the platform is a paved road rather than a wall. Teams with a genuine reason to go around it may, and the platform team treats that as information about a gap rather than as defection. Where the abstraction is mandatory, the workarounds happen anyway and are simply not recorded.
The buying decision underneath is the same one running through cloud repatriation and software sprawl: what a company is willing to own versus rent. Building the platform is choosing to own the abstraction and to keep paying for it in engineering time, forever, in exchange for it fitting.
