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.
A familiar setup: several product teams share a handful of long-lived staging environments, and getting one means filing a ticket and waiting days. The predictable result is that people test in production, or do not test at all, and the infrastructure team stops building anything because it has 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
The common mistake is to make the developer portal the only way in. It quietly shapes the whole control plane around what a web form can express. Build the API first and make the portal a thin client over it, and the CLI, the CI integration and the chat command stop being separate projects — each is a small client of an interface that already exists.
The portal is a client of your platform. If it is your platform, everything else has to be built twice.
The measure that mattered
The obvious measures are provisioning time and ticket volume, and both fall sharply once environments stop being scarce. The change worth caring about is quieter: people start opening draft pull requests just to try something, because trying something has become free. That is what a platform is for.