I've seen two kinds of internal platforms. The first kind gets a team, a roadmap, and a slick dashboard — and is quietly abandoned eighteen months later. The second kind has almost no fanfare, and the company can't remember how they shipped before it existed. The difference isn't technology. It's whether the platform answers a business question.
The only metric that matters
Forget uptime, forget 'platform adoption', forget the dashboard. The metric is time-to-production for a real workload: from a fresh environment to a deployed, observed, rollback-capable service. If your platform doesn't move that number by a meaningful amount, it's a hobby, not a platform.
Build the golden path, not the infrastructure
- Golden path: one blessed route from code to production — templates, CI, observability, rollback — so the default choice is the safe one. The platform's job is to make the right way the easy way.
- Enforce a few invariants, not everything: every service gets a health check, structured logs, a dashboard, and a runbook. Automated where possible, manual where not.
- Cost is a first-class signal: tag everything, show teams their own spend, and make 'can we afford it?' part of the design conversation.
- Self-service over tickets: the platform team should be writing software, not filling requests. If engineers need to ask permission to deploy, the platform is overhead.
# one command, on every service, forever
up create my-service --stack web
# -> repo, CI, healthcheck, dashboard, runbook, alerts
up deploy # zero-downtime, auto-rollback on bad health
up cost # this service, this month, by resourceWhen not to build a platform
If you have fewer than, say, fifteen engineers, you almost certainly don't need an internal platform. You need good defaults: a shared template repo, CI, and a couple of runbooks. Platforms are how a company of 200 behaves like a company of 20 — they're leverage, and leverage only pays off when there's enough work to amplify.
Ask: if the platform vanished tomorrow, how much business value disappears? If the answer is 'not much', you've built a dashboard. Fix the metric, then fix the platform.
The best platforms are boring. They quietly compress the distance between an idea and a deployment, and the product teams get the credit. That's fine. That's the job.