A developer is packed and ready to ship. The weather is perfect, the code is done. Then they’re told to raise a Jira ticket to provision a database. Days pass. The weather window closes. Context is lost, momentum is gone.
This is the reality of most code-to-production paths: manual handoffs, inconsistent environments, and cognitive overload. At our latest Code to Production meetup, we broke down why the journey from commit to production keeps failing and what platform engineers can actually do about it.
The Mountain Metaphor
Think of developers as hikers. They want speed, the best view, and they want to get there now. Platform engineers are park rangers. They care about safety, sustainability, and making sure the mountain doesn’t burn down.
Both groups share the same goal: get code to production, where it generates revenue. But they clash because they define “done” differently. For a developer, deploying is the finish line. For a platform engineer, it’s the starting point. Monitoring, scaling, incident response: the work continues long after code is live.
When things go wrong at 3 AM, it’s the platform team grabbing the stretcher. That dynamic breeds resentment if it’s not addressed with systems, not just goodwill.
The Problems Everyone Recognizes
These are not new observations. But they persist because organizations keep trying to solve them with process instead of platform.
“It works on my machine.” Local and test environments look like a nice meadow. Production looks like a steep, icy cliff. Manual configuration creates drift, and drift is where trust between developers and platform engineers goes to die.
“You build it, you run it.” In practice: you build it, you containerize it, you configure CI/CD, you provision infrastructure, you appease the cloud gods, you set up alerting, and then you try to run it. When developers need to hold fifty concepts in their heads, it’s no wonder things take time.
What Actually Works
Pre-Build the Campsite
How often do developers feel like they have to provision half the world before writing a single line of business logic? Platform engineers should build the campsite before the hikers arrive: infrastructure scaffolding, self-service provisioning, and sensible abstractions.
Two things matter. First, abstract at the right level. Understand who’s going to use your platform, what they need, and how they work. Second, prioritize basic needs over luxury features. A place to pitch a tent matters more than a fully flushable toilet.
Pave the Roads: Unified CI/CD
Nobody benefits from developers wandering through dirt paths or, worse, deploying manually straight into environments.
We saw this firsthand. A client had Jenkins pipelines maintained individually, patched together, with no consistency. Some developers bypassed the pipelines entirely and deployed manually. The fix was creating a network of paved roads using GitHub and reusable workflows: pipelines maintained from a central point, one consistent road architecture that everyone uses.
The caveat: self-service is only valuable if it takes you where you want to go. A paved road that goes in circles is useless.
Declarative Configuration and GitOps
What if you could change the terrain by changing the map? That’s declarative configuration. You define the desired state, and the system makes it real.
A concrete example: a client with multiple clusters, each running 500+ pods. Their disaster recovery plan involved a hot mirror for the main messaging solution, but all adjacent workloads had to be migrated manually. Failover took hours.
Using declarative configuration with Argo CD, we reduced that to changing one variable. All workloads spun up automatically. Clusters could be kept warm, or even cold, with near-instant failover. Hours became minutes.
The Results
When platform engineering is done well, three things change.
- Developers travel light. The platform handles the heavy lifting. Developers focus on writing code. The paths are there, the guardrails are in place, and the backpacks are light.
- Feature delivery accelerates. Code sitting in a repository generates zero revenue. Code running in production does. Make it easy for people to ship, and they will.
- Safety becomes structural. Instead of relying on people to not make mistakes, you make it hard to get off the path. Guardrails, not guidelines. One example: a client got notified that production certificates were expiring in one hour. The scramble to renew them across all systems was pure chaos. That’s a problem you solve with automation, not heroics.
What’s Next
Platform engineering isn’t a nice-to-have. It’s the difference between developers who ship and developers who survive.
If your team is stuck in the wilderness, we should talk. Irori works with engineering organizations across Sweden to build the trails that make code-to-production reliable, fast, and boring in the best possible way.
Check out our upcoming meetups at irori.se or reach out directly
