Internal developer platforms: prove the journey before buying tools

The database request is easy to find. Getting a usable database still takes days. For a platform engineering lead, that gap is the place to start an internal developer platform investment case: which part of the developer’s work will actually change?

A portal can make services discoverable without changing approval queues, access controls or operational handoffs. Better navigation has value, but it will not substantiate a claim that teams can deliver software faster. Before selecting tools, choose a recurring journey and define the outcome the platform team will support.

Locate the expensive part of the journey

Follow several recent requests from the developer’s first attempt to a usable result. Separate active work from waiting. A database journey might include finding the right service, supplying data classifications, gaining approval, provisioning, receiving credentials and confirming that the application can connect. A provisioning job that finishes successfully proves only one part of that chain.

Ask who experiences each delay and who controls it. Missing instructions point towards better documentation. Repeated copying between systems may justify workflow automation. Inconsistent combinations of infrastructure, access and operating responsibilities may warrant a supported platform capability. These are alternatives, not a mandatory maturity ladder.

The CNCF Platforms White Paper treats a platform as an internal product shaped by stakeholder needs and explains that its team need not build every underlying capability. The implication for your budget is useful: fund the smallest supported change that addresses the observed constraint. Reimplementing a service already provided well elsewhere adds maintenance before it adds value.

In a hypothetical pilot, a new portal reduces misdirected database requests but leaves the approval queue unchanged. Developers find the service more easily; elapsed time to first successful use barely moves. Retain the navigation improvement, then test whether pre-approved request types or clearer ownership can address the remaining delay. More portal features would not answer that finding.

Make the demonstration survive a failed request

A polished service-creation demo starts from an empty repository and ends with a working application. Your evaluation should also start from awkward intermediate states: a repository exists but infrastructure creation failed; access was granted to the wrong group; a user retries after losing the browser session.

Backstage Software Templates can load code skeletons, substitute variables and publish to services such as GitHub or GitLab. Its documented task flow includes step-level failure logs and a start-over action that creates a new execution with pre-filled parameters. Cancellation stops subsequent steps, while cancelling the current step depends on that step supporting it.

Those details change what you should ask a prospective implementation team to demonstrate. A retry needs a defined way to recognise resources created by the previous attempt. Cancellation needs an explicit answer about what remains and who cleans it up. Neither a new execution nor a stopped workflow should be accepted as evidence that partially created resources have been removed.

Set an acceptance test around the resulting service. For a database, require the intended application identity to connect with the agreed permissions, a named cost owner, a supported backup arrangement and a visible route for help. Then deliberately interrupt an approved test request and inspect the remaining resources. The evaluation is about the whole implemented journey; the template engine is one component.

Include an exception that the standard template cannot fulfil. An unusual requirement should reach an accountable owner with a clear decision path. Otherwise the platform may merely move difficult work into private messages while its dashboard records apparently healthy completion rates.

Price the service you will have to run

Platform investment commits the organisation to maintaining a dependency used by other teams. Budget for template changes, provider API changes, incident response, documentation, support and migration of existing users. A template that is easy to create can still be expensive to keep compatible with the organisation’s evolving standards.

Separate ownership of the developer journey from ownership of the underlying infrastructure. When provisioning fails, developers need one clear route to resolution; they should not have to determine whether the fault belongs to the portal, an automation worker or the infrastructure service. Agree how the platform team coordinates those owners and communicates progress.

Also decide which parts of an existing application the platform will manage. Creating new services and adopting older ones are different workloads. A roadmap that assumes every team starts with a blank repository can underestimate the support needed by the teams whose work is hardest today.

Compare the proposed running cost with the simpler intervention. If documentation and an accountable request owner remove most of the friction, that may be the right initial investment. If repeated teams need the same integrated outcome and maintaining individual scripts is becoming costly, the case for a platform is stronger.

Approve expansion against observed work

Run comparable requests through the current and proposed routes, recording time to usable service, manual interventions, rework and support effort. Keep complex exceptions separate from routine requests so that an easier pilot workload does not masquerade as an improvement. Ask teams why they choose or avoid the route, and distinguish voluntary preference from mandatory adoption.

Proceed when the pilot demonstrates a useful change, the failure path works and an operating team accepts the ongoing commitment. If one of those conditions is missing, address that specific gap before expanding the catalogue. For the next investment review, use developer-journey measures that show whether platform engineering is working to connect adoption with the work it was meant to improve.