The lifecycle in this series applies to more than AI pilots. Internal developer platforms go through the same journey, and they suffer from the same confusion between growth and maturity. A platform that started as one team's starter template can end up serving dozens of services without anyone deciding that it should be relied on like a product. Then, one day, a change to a shared template breaks every deployment in the company on the same afternoon.
Platforms deserve particular attention in an AI era. Coding agents, AI services and governed tool access increasingly run on top of an internal platform: shared pipelines, approved model gateways, secrets handling, templates with the right controls already in place. If the platform is not trustworthy, nothing built on it can be.
CloudNala's view: a platform graduates by becoming a product, not by getting bigger. The evidence for promotion is about product behaviour: versioned interfaces, support, documentation, service levels and, above all, whether teams choose it when they have a real choice.
Waterberg Mining Services is fictional, and its systems and figures are illustrative.
Waterberg's platform
Waterberg's internal platform is called Headframe, after the structure above a mine shaft that everything passes through. It began two years ago as a repository template the fleet telemetry team created to stop rebuilding the same pipeline, logging and secrets setup for every new service. Other teams copied it. Then the template gained a deployment pipeline, a shared cluster, a service catalogue and, most recently, a pre-configured route to approved AI models through a gateway.
By the time the portfolio was labelled (see Part 1), fourteen services ran on Headframe. Its two maintainers were still part of the fleet telemetry team and supported the platform in whatever time they had left.
Three shapes of a platform
Experiment: a template one team uses. Its purpose is to save that team effort. The evidence is simple: does it actually save time compared with building each service from scratch? Breaking changes are expected and fine.
Incubating: a paved road a few teams adopt. The platform now has users who did not build it. The question changes: do other teams pick it when they could build their own, and what do they need to keep doing so? Interfaces start to need versions, and changes need notice.
Trusted production: a product with owners and service levels. Teams are now told, or at least strongly encouraged, to depend on it. That means it must behave like something you would buy: a product owner, a roadmap, published support, service levels, versioned interfaces with a deprecation policy, and documentation a new team can follow alone.
Headframe was clearly beyond Experiment. It was not Trusted production. It had fourteen consumers, no product owner, no service levels and no deprecation policy. The honest label was Incubating, and the gap to Trusted production was mostly organisational rather than technical.
The evidence stack for promotion
Product management. A named product owner, a public roadmap and a way for teams to ask for things. Without these, the platform is shaped by whoever shouts loudest.
Support. Published support hours, an escalation path and response targets. Teams building on the platform need to know what happens when their deployment is stuck at four in the afternoon on a Friday.
Service levels. Objectives for the things teams depend on: pipeline success rate, deployment time, portal and catalogue availability. Measured, not aspired to.
Interfaces. Versioned templates and APIs, and a deprecation notice period. Waterberg chose ninety days for breaking changes to templates and pipeline steps. The number matters less than the fact that teams can plan around it.
Documentation. Golden paths that a new team can follow without asking the maintainers. The test is simple: give the documentation to a team that has never used the platform and watch.
Adoption. Evidence that teams choose the platform, and the reasons some do not. This is the layer platform teams most want to skip, and the one they most need. A mandated platform with weak evidence higher in the stack becomes an expensive bottleneck that teams route around.
Voluntary adoption as the real test
Mandates are tempting. Requiring every team to use the platform guarantees adoption numbers and simplifies governance. It also removes the most useful signal a platform team has: whether the platform is good enough that people would choose it anyway.
Waterberg's reviewer interviewed teams that used Headframe and two teams that had chosen not to. The users valued the pre-configured security controls and the AI gateway route, which saved them weeks of approvals. The two teams that stayed away had the same complaint: the pipeline took over twenty minutes for a small change, and they could not get an answer about when that would improve.
That finding did not block promotion, but it shaped the first item on the new product owner's roadmap. It would not have surfaced from a mandate.
Platform-specific blockers
Using the blocker test from Part 5, Headframe's review found four blockers to Trusted production:
- No product owner separate from the fleet telemetry team.
- No deprecation policy, so a template change could break consumers without notice.
- The shared cluster's recovery had never been rehearsed, and fourteen services depended on it.
- The AI gateway route had per-team budgets, but nobody owned the overall platform cost.
Follow-ups included pipeline speed, a better service catalogue and a self-service onboarding guide.
Waterberg resolved the blockers over two months. The most significant change was organisational: Headframe got a product owner and a third engineer, funded centrally rather than from the fleet telemetry budget. The recovery rehearsal took a full day and was the most valuable day of the whole exercise. Headframe was promoted to Trusted production at the following lifecycle review.
Graduation is not the end of change
A Trusted production platform still changes constantly. What changes is how. New capabilities start as Experiments inside the platform, with a small group of volunteer teams, and graduate into the paved road when they have evidence of their own. Headframe's next addition, a template for agent-based services with pre-approved tool permissions, is currently an Experiment used by one team.
That nested lifecycle is what keeps a platform both stable and useful. For more on why platform engineering matters before AI arrives, see The case for platform engineering and Platform engineering for the citizen-and-agent era.
Next: Part 7, Archived does not mean failed. All parts are on the series page.
How CloudNala can help
We help organisations assess their internal developer platforms against the evidence a product needs: ownership, support, service levels, versioned interfaces, documentation and voluntary adoption. We can run the adopter interviews, rehearse platform recovery with your team, and help shape a roadmap that turns a large platform into a trusted one.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book a Technology and AI Maturity Assessment or write to us at consult@cloudnala.co.za