The pull request is the right unit of infrastructure
If getting an environment means asking a person, your platform has a queue in it. The fix is to make the pull request provision its own world.
Eight product teams shared three long-lived staging environments. Getting one meant filing a ticket and waiting three days on average. The predictable result was that people tested in production, or did not test at all, and the infrastructure team stopped building anything because it had become a queue.
The usual response is to add more environments. That buys a few months and makes the queue slightly shorter. The actual problem is that an environment is a scarce shared resource at all.
Scarcity is the bug
Long-lived shared environments accumulate state, drift from production, and develop owners who are reasonably protective of them. Every one of those properties makes them more valuable and therefore more contested. Adding a fourth does not change the dynamic — it just moves where the argument happens.
If an environment is instead created by opening a pull request and destroyed by closing it, none of those properties can form. It has no accumulated state because it did not exist yesterday. It cannot drift because it is rendered from the same declarations as production. Nobody defends it because it is going away.
What this actually requires
- A manifest per service declaring what it needs — database, topic, bucket, secret — rendered into real resources.
- A control plane that reconciles continuously, so a half-created environment repairs itself rather than leaving a mess.
- Seed data that is statistically faithful but never a copy of production, so compliance is not in the critical path.
- Teardown that is as reliable as creation, or your cost argument evaporates within a quarter.
That third point is the one most teams underestimate. Environments are useless without data that behaves like the real thing, and copying production records turns a platform project into a compliance project. Generating a faithful dataset from the schema is more work up front and removes an entire approval path.
Build the API before the portal
I got this wrong. For two months the developer portal was the only way in, and that shaped the whole control plane around what a web form could express. Rebuilding it as a thin client over a proper API is what unlocked the CLI, the CI integration and the Slack command — all of which existed within a week once the API was the real interface.
The portal is a client of your platform. If it is your platform, everything else has to be built twice.
The measure that mattered
Provisioning went from three days to four minutes and infrastructure tickets fell by 94%. Those are the numbers that go in the summary. The change I actually cared about was quieter: people started opening draft pull requests just to try something, because trying something had become free. That is what a platform is for.