An internal platform earns its maintenance cost by reducing the work required to ship and operate a service. Mandatory adoption can hide whether it actually does that. I would start with the tasks teams repeat and measure how much help they need to complete them.
Start with a recurring interruption #
Find a task that regularly pulls application engineers away from useful work: requesting a database, understanding an alert, or discovering how to ship a service. Follow someone through it before designing a portal.
Make the default explain itself #
A service template should tell its user what it creates, who owns the resources, and what happens when it is removed. Hidden automation can turn a ten-minute convenience into a week of uncertainty.
Own the lifecycle #
Creating a service is the first operation. Upgrading its runtime, transferring ownership, restoring a backup, and removing its resources are part of the same product. A template that handles creation but leaves recovery undocumented transfers the hard work to application teams.
Version the platform contract and publish migration paths. Generated configuration should record which version produced it so a failed upgrade can be traced to a specific change.
Measure adoption alongside friction #
Usage alone is a weak signal when the platform is mandatory. Pair it with task completion time, support requests, and the proportion of teams that can recover from a failed operation without specialist help.
Separate measurements by task and team experience. A falling median can hide a long tail of teams waiting for specialist intervention. Track failed attempts and support escalations alongside completion time.
Document the supported extension points and the cost of opting out. Teams with different workload constraints need a clear boundary between what the platform owns and what they will operate themselves.