← BLOGHOME

Feb 18, 2026 · 3 min read · Real Engineering Lessons

Reducing Infrastructure Requests From Hours to Minutes

One of the most useful platforms I worked on wasn’t customer-facing. It helped developers complete common infrastructure tasks without waiting for every request to be handled manually.

A developer needed a resource. The provisioning itself was predictable, but the waiting around it wasn’t. At TRADE IN TECHNOLOGY, I helped build an internal self-service infrastructure platform to address that gap. Before that work, common requests often moved through a familiar sequence: a developer asked for a resource, someone from DevOps collected the missing information, the request waited for availability, and an engineer executed a series of manual steps. The commands themselves weren’t always time-consuming. The handoffs were. A request that required a few operations could take hours from beginning to end because it depended on handoffs, clarification, and somebody having time to perform it.

Beyond the Commands

It would be easy to describe the project as a web interface in front of some scripts, but most of the work was behind that description. The real work was turning operational knowledge into a safe process. Which information was required before provisioning could begin? Which options should developers be allowed to choose? What defaults would prevent common configuration mistakes? Which operations needed approval? How would somebody understand what had happened if a task failed halfway through? We needed to make the common requests faster without making unsafe actions easy. We built reusable workflows with TypeScript, NestJS, Python, and Ansible, supported by a React interface. Developers could request resources and launch common operational tasks through a consistent flow. The automation validated the input, executed the appropriate steps, and returned a clear result. Provisioning workflows that previously took hours could be completed in minutes.

Self-Service and DevOps

We weren’t trying to remove infrastructure engineers from the process. We wanted to stop requiring them to repeat the same predictable work. The DevOps team already had the knowledge. Our job was to make the common parts reusable, so application teams had more independence without ignoring standards around security, configuration and access. The unusual requests still needed human judgment. The common requests no longer needed a new conversation every time. It also meant the DevOps team spent less time acting as a human queue for routine operations.

The Internal User Experience

Working on the platform also reminded me that internal users are still users. If a tool exposes infrastructure terminology without explaining the choices, developers will continue asking for help. If errors only show the output of an automation script, the platform has moved the manual work without improving the experience. If the workflow is slower than sending a message, people will return to sending messages. We had to think about the complete experience: sensible defaults, validation before execution, status during longer operations, useful error messages, and enough history to investigate problems. The frontend wasn’t just decoration around the automation. It translated an operational process into something another engineer could use without knowing every command behind it. Automation is often discussed in terms of execution time: a script completes in thirty seconds instead of a person spending ten minutes on commands. That matters, but it’s only part of the value. The bigger improvement came from removing the waiting between people. A self-service workflow didn’t need to find a free time in someone else’s day. It ran with the same validations and sequence every time.

It also reduced configuration differences and some of the small mistakes that happened when the process depended on memory. I was closer to infrastructure work during this project than I had been before, so I started seeing more of what happened after an application was merged: how environments were configured, how access was managed and how much a routine operational request could delay a feature. The platform wasn’t customer-facing and nobody outside engineering was likely to notice it. Inside the team, a developer could ask for a resource and have it in minutes instead of waiting for a conversation that might take hours. That was the part people noticed.