Why your internal developer platform becomes another ticketing system
"I need a production PostgreSQL" hides identity, Terraform, network, secrets, policy, and a queue — unless you design against the default.
The internal developer platform promise is simple: developers request what they need, the platform delivers, everyone ships faster. The reality in year two is familiar: a portal, a form, a ticket number, a platform team queue that grows faster than headcount. Self-service became another place to wait.
This is not because platform engineers are slow or developers are greedy. It is because the request 'I need a production PostgreSQL' is not one thing. It is identity provisioning, infrastructure as code, network segmentation, secrets management, backup policy, monitoring hooks, cost allocation, compliance evidence, and often a human who must approve something the form cannot see. Hide that chain behind a button and you get ticketing with better typography.
Constrange helps platform teams name the real workflow — then decide what to automate, what to template, and what must stay human. Without that honesty, every IDP becomes Jira with a logo.
The hidden chain behind every simple request
Developers experience requests as nouns: database, queue, bucket, cluster. Platforms experience them as verbs across systems: create principal, attach policy, apply module, peer VPC, inject secret, register service, wire alert, tag for chargeback, document in CMDB. The noun is the tip. The chain is the iceberg.
| Layer | Work hidden in the request |
|---|---|
| Identity | Service account, IAM roles, rotation, least privilege |
| Infrastructure | Terraform module, sizing, HA, backups, patching |
| Network | Subnet, security groups, private link, egress rules |
| Secrets | Credential store, injection into workloads, audit |
| Policy | Data classification, retention, encryption, region rules |
| Operations | Monitoring, on-call routing, runbooks, cost tags |
Why portals default to tickets
Portals are easy to buy and demo. Deep automation is hard and political. A form that opens a ticket satisfies the demo and the audit trail. It does not satisfy the developer who needed the database on Tuesday. Platform teams under pressure ship the portal first and promise automation later. Later becomes never because the ticket queue is full of exceptions that do not fit the template.
Exceptions are the real product. The happy path is a blog post. Production requests arrive with legacy dependencies, shared services, wrong region, special retention, and a security question the form did not ask. Each exception becomes a manual step. Manual steps do not scale. The queue grows. Developers learn the unofficial path — ask in Slack, DM the platform lead, use the old Terraform repo. The IDP becomes shelfware with a login page.
Self-service is an outcome, not a UI
True self-service means the developer gets a working, policy-compliant resource without a human touching the request — for a defined class of request. That requires golden paths: opinionated templates where choices are pre-made, guardrails where choices are bounded, and fast feedback when the request is out of scope.
Golden paths are not restrictive for sport. They are how platforms absorb complexity so developers do not have to become part-time network engineers. The trade is explicit: fewer knobs, faster delivery. Teams that refuse to standardise cannot automate — they can only ticket.
- Catalogue the ten requests that consume eighty percent of queue time
- Automate one path end-to-end before adding portal features
- Measure time-to-ready, not time-to-ticket-created
- Publish what the platform will not do without human review
Identity and policy: where tickets reproduce
Identity is the slowest layer. Who is allowed to request production resources? Which team owns the cost? Which roles can access secrets after provision? Platforms that automate Terraform but leave identity manual recreate the queue at the permissions step. Policy engines help when rules are codified. When policy lives in someone's head, every request is a consultation.
Terraform is not the whole platform
Teams invest in modules and pipelines, then wonder why developers still wait. Applying infrastructure is one step. Wiring observability, registering in service catalogue, attaching backup policy, and handing credentials to the workload are often separate systems with separate tickets. End-to-end automation means one transaction across those systems — or honest acknowledgment that the developer must complete steps two through five manually.
| Ticketing trap | Self-service outcome |
|---|---|
| Form creates Jira | Form triggers provisioned resource |
| Status page shows 'in progress' | Status shows resource health and endpoints |
| Exceptions handled in Slack | Exceptions routed to defined approvers with SLA |
| Documentation links to wiki | Embedded policy and live dependency checks |
| Metrics: tickets closed | Metrics: time-to-ready and developer retry rate |
Developer experience without lying
Developers resent platforms that pretend instant delivery while the queue says five days. Honest UX sets expectations: this request is automated in minutes; that request needs security review and typically takes two days. Better still, shift review left — policy checks at submit time, not after a human reads the ticket.
Developer experience also means failure messages that teach. 'Request denied' without reason breeds shadow IT. 'Denied: production databases in this region require data residency approval — link here' breeds trust. Platforms earn adoption when they explain the constraint, not when they hide it behind a ticket.
“A platform that cannot say no in code will say no in queue depth.”Constrange
Organisational antibodies
Platform teams compete with existing gatekeepers: security review, architecture board, finance allocation, operations change windows. Automating Terraform without aligning those gates moves wait time from platform to security. Programme success requires sponsors who will codify policy — not exceptions stored in email.
Constrange often finds the IDP ticket queue is doing the work architecture review never finished: deciding boundaries, standards, and ownership in real time, under pressure, per request. That is expensive governance. Cheaper to decide once, encode in policy, automate the eighty percent, and reserve humans for genuine exceptions.
Escaping the ticketing default
- Map the full chain for top requests — identity through operations
- Pick one golden path and automate end-to-end including failure messages
- Codify policy checks before submission, not after ticket creation
- Measure developer outcomes: time-to-ready, not tickets opened
- Retire unofficial paths when golden path proves reliable — or document risk
When tickets are correct
Some requests should be tickets: novel architectures, cross-border data, production access for humans, policy exceptions with executive sign-off. The goal is not zero tickets. It is zero tickets for requests that should be automated. Platforms that ticket everything and platforms that automate everything both fail. Discrimination is the work.
Platform product management
Treat the IDP as a product with a backlog ranked by developer pain and automation feasibility — not as internal infrastructure that accretes features. Interview developers who stopped using the portal. They will show you the shadow path. Fix that path or kill it deliberately.
Roadmaps that prioritise another integration over shortening the top queue are choosing visibility over outcomes. Developers do not want more tiles. They want Tuesday's database on Tuesday.
The platform team's capacity trap
Every manual step in the chain consumes platform engineering time that cannot automate the next path. Ticket queues are not steady state — they are a tax that grows with adoption. Teams that measure success by portal launches instead of provisioned resources recruit demand faster than they remove toil.
Capacity planning for platform teams must include automation debt: hours spent per request type, recurrence of exceptions, and shadow path volume. Without that data, hiring more platform engineers buys a larger ticket team, not self-service.
Questions for your platform review
- What percentage of portal requests complete without human touch?
- Where does the chain break after Terraform apply?
- Which exceptions recur monthly — and why are they not policy or template?
- What do developers use instead of the portal — and is it safer?
- Who owns end-to-end time-to-ready, not ticket closure?
Honest answers separate platform engineering from portal administration. Both are work. Only one ships faster.
Frequently asked questions
Is some ticketing inevitable?
Yes. Genuine exceptions need humans. The failure is ticketing the routine eighty percent.
Should we buy an IDP product or build?
Buy for portal and catalog patterns; build golden paths and policy for your estate. Neither alone avoids the queue without integration work.
How do we prioritise automation?
Rank by request volume times manual steps times developer wait. Automate the highest product of the three first.
What metric proves we escaped the trap?
Median time-to-ready for standard requests, measured from submit to usable resource — not ticket closed.