Platform Engineering is a Product, Not a Script

Most internal developer platforms (IDP) are just expensive ways to hide the fact that your infra team doesn't trust your product team.

We spent the last year watching teams try to abstract away Kubernetes. They usually end up building a worse version of the AWS console written in half-baked Go templates.

If your platform requires a 40-page Wiki to deploy a Hello World app, you haven't built a platform. You've built a gate.

The Fallacy of the "Single Pane of Glass"

Every vendor wants to sell you a single pane of glass. In reality, you're just giving your engineers another tab to keep open while they wait for a Jenkins job to fail.

We started by building a custom UI for deployments. We thought we were helping. We weren't.

Engineers don't want a shiny dashboard to click buttons. They want to stay in their terminal or their IDE.

We eventually deleted 4,000 lines of React code and replaced it with a CLI tool called g11. It does three things: authenticates, lints the .git11.yaml, and pushes to a manifest repo.

If an engineer has to leave VS Code to see why their pod is crashing, your DX is broken. We moved our observability links directly into the PR comments using GitHub Actions. Use the tools your team already likes.

Abstractions are Leaky and Dangerous

Don't try to hide the infrastructure. It’s like hiding the engine of a car under a welded-on hood.

When things break—and they will—your developers need to understand what's happening. If you wrap kubectl in ten layers of proprietary scripts, nobody can debug at 3 AM.

We tried to standardize on a single values.yaml for every service in the company. It worked for exactly two weeks.

Then the ML team needed GPUs. The edge team needed custom headers. The legacy monolith needed more than 5 minutes for a graceful shutdown.

Instead of a rigid abstraction, we moved to a "Golden Path" model. We provide a sane default template for 80% of use cases. If you need something weird, you fork the Helm chart and own it.

Support the 80% with automation. Support the 20% by staying out of their way.

The Self-Service Trap

Self-service doesn't mean "build a form for everything." It means remove the human in the middle.

We used to have a Slack channel called #ops-requests. It was a graveyard of productivity.

We replaced it with a Terraform provider and a set of GitHub-integrated CRDs. Now, if a dev needs a new S3 bucket, they add five lines to their repo.

If your "self-service" platform sends a Jira ticket to an Ops engineer for approval, you’re just doing Ops with a more expensive UI.

Automate the policy, not just the resource creation. Use OPA (Open Policy Agent) to check if the bucket is private by default. If it passes, merge it. If it doesn't, fail the CI.

Measure the Right S**t

Stop measuring "number of deployments per day." It’s a vanity metric. You can deploy bugs 100 times a day; it doesn't mean you're good.

Measure the "Time to First Successful Deploy" for a new hire. On day one, can they get code into a staging environment without asking for help?

When we started, our MTTD (Mean Time to Deploy) was 45 minutes because of a bloated CI pipeline. Most of that was spent waiting for a shared DB to migrate.

We broke the dependencies. We used ephemeral environments via vcluster. We got it down to 6 minutes.

Productivity is a function of feedback loops. If your feedback loop is 45 minutes, your engineers are browsing Reddit. If it's 6 minutes, they're focused.

The YAML Tax

YAML is the lead paint of the cloud-native era. It’s everywhere, and it’s toxic in large quantities.

At one point, our app-deploy repo had 14,000 lines of boilerplate. Changing a DNS entry required touching six different files.

We switched to CUE. It allowed us to define schemas and validate data before it ever touched a cluster.

If you are manually copy-pasting env blocks across thirty microservices, you are the bottleneck. Build a generator or use a configuration language that supports logic.

Don't be a Hero

Platform teams often suffer from a martyr complex. They think being paged at 2 AM for a dev database is part of the job.

It’s not. It’s a failure of architecture.

If the platform is down, the company stops. Treat your platform like a tier-0 service. This means proper on-call rotations, SLOs that actually matter, and a refusal to do manual toil.

Every time you do a manual fix, you're stealing time from a permanent solution. Write the script. Fix the provider. Delete the manual step.

Stop Building, Start Integrating

Before you write a single line of code for your platform, ask why you can't buy it or use an open-source tool.

We almost built a custom secrets manager. Then we realized HashiCorp Vault already exists and works better than anything we’d write in a month.

Your value is in the glue—the specific way your company’s identity provider connects to your cloud accounts and your CI/CD.

Focus on the unique constraints of your business. If you’re spending time writing a wrapper for an AWS API, you’re wasting money.

The Takeaway

Build for the engineer who is tired, caffeinated, and just wants to ship their feature.

Make the right way the easiest way. If you make the secure, scalable path the path of least resistance, people will follow it. If you try to force them with mandates and tickets, they will find a way around you.

Documentation is what you write when you failed to make the abstraction intuitive. Stick to the terminal, automate the policy, and get out of the way.