Platform Engineering is a Service Desk with Better APIs

Building an Internal Developer Platform (IDP) is the fastest way to burn $2M and three years of engineering headcount for a tool nobody uses.

We see it constantly at git11. Companies build a massive, complex UI on top of their infrastructure, name it something like 'Project Zenith,' and then wonder why their senior engineers are still manually editing Helm charts through SSH.

Most platforms fail because they focus on 'abstractions' instead of 'reduction.' Your developers don't want a new dashboard. They want to stop caring about IAM roles and VPC peering.

The Golden Path is a Lie

If you tell a developer there is a 'Golden Path,' you are implying every other path is made of dirt. This is wrong.

When you force a strict abstraction, you create a ceiling on what your best engineers can do. They will eventually hit a wall where your platform doesn't support a specific AWS feature, and they’ll fork your YAML or go around you entirely.

Don't build a cage; build a library. A platform should be a set of sensible defaults that are easily overridden.

If I need a custom nginx.conf, I shouldn't have to submit a PR to the platform team to add a new field to your ServiceDefinition.yaml. I should be able to drop my config in and go.

Stop Building UIs

Every minute you spend on a custom React dashboard for triggering deployments is a minute wasted. Developers live in the terminal and the IDE.

If your platform requires me to open a browser to check why a build failed, you've already lost. Use the CLI. Use GitHub Actions. Use your code.

At git11, we found that the most successful IDPs are actually just well-documented git workflows. A developer pushes to a specific branch or tags a release, and the 'platform' handles the rest behind the scenes.

Backstage is fine for discovery, but it’s a terrible place to do actual work. It’s an atlas, not a cockpit.

The 'Day 2' Problem

Provisioning a database is easy. Everyone has a Terraform module for a Postgres RDS instance. That isn't a platform; that's just basic automation.

Real platform engineering is what happens when that database hits 90% storage capacity, or when a developer needs to restore a snapshot from three hours ago to a staging environment.

If your platform doesn't automate the boring operational tasks—the stuff that keeps people on call—it isn't a platform. It's a shiny wrapper on top of a messy reality.

You should measure success by the number of Slack tickets that don't reach your SRE team. If people are still asking "how do I reset my staging password?", your platform is broken.

Standardize on Outcomes, Not Tools

Don't mandate that everyone uses Go. Do mandate that every service must export Prometheus metrics on :9090/metrics and have a healthz endpoint.

When we analyzed repository patterns for our customers, the highest-velocity teams were those with the least amount of boilerplate internal tooling. They used off-the-shelf stuff like Terraform and GitHub Actions with very thin layers of glue code.

Avoid the 'Not Invented Here' syndrome. If you find yourself writing a custom scheduler or a proprietary deployment engine, stop. You are not Google. You are a company trying to ship features.

The Secret Sauce is Metadata

Your platform should be smart enough to know who owns what. This is where most organizations trip up.

We recommend a catalog-info.yaml or a .git11.json file in the root of every single repo. It should define the owner, the Slack channel for alerts, and the production URL.

Once you have this metadata, you can automate everything from PagerDuty rotations to cost attribution without asking a single question. Without it, you’re just guessing.

Kill the 'Platform Team' Mentality

You are a product team. Your customers are just in the same building as you.

Talk to them. If they find your platform annoying, it is annoying. Don't tell them they're wrong; fix the friction.

If a platform isn't saving a developer at least 4 hours a week, it’s just additional overhead they have to learn. They will resent it, and they will find ways to bypass it.

Concrete Takeaway

Delete your internal UI effort. Focus on making your provider.tf files and GitHub Action templates so simple that a junior dev can’t mess them up and a senior dev doesn’t feel insulted by them.