Internal Developer Platforms: Treat Them as Products

I’ve built internal tooling at three companies now: a mobility startup, a fintech startup, and most recently the early groundwork at my infrastructure startup. At least once, I got it badly wrong. The lesson: stop building internal platforms nobody asked for, and talk to your engineers first. If they’d rather copy-paste bash scripts than use your platform, that tells you everything.

At the fintech startup, we built a deployment system that was technically sound and architecturally clean. Nobody used it. Engineers kept SSHing into boxes and running scripts manually because our “platform” added steps instead of removing them. That was humbling.

The mistake was obvious in hindsight. We built what we thought engineers should want instead of solving what actually slowed them down.

Platforms Are Products

This is the part most engineering leaders get backwards. You wouldn’t ship a product feature without talking to users. But somehow, platform teams spin up for months in isolation, emerge with a Kubernetes abstraction layer, and then act surprised when adoption is flat.

Your developers are your users. They have deadlines, context-switching overhead, and zero patience for tools that add friction. If your platform doesn’t make their Tuesday afternoon measurably better, it’s shelf-ware.

At the mobility startup, we got this right. We started by sitting with engineers and listing every manual step in their deploy process. Not what we imagined the pain points were. What they actually were. Turned out the biggest time sink wasn’t CI/CD at all. It was environment provisioning. Engineers were burning hours configuring staging environments that drifted from production within a week.

So we fixed that one thing first. Standardized environments, one command to spin up, automatic teardown. Adoption was immediate because it solved a real problem engineers hated.

Paved Roads, Not Walls

The best platforms are opinionated but not authoritarian. You set strong defaults, make the common case trivial, and leave an escape hatch for the 10% of services that genuinely need something different.

The trap is mandating usage. The moment you force teams onto your platform without it being obviously better, you’ve created resentment and shadow infrastructure. I’ve seen this happen. Engineers are resourceful. They will find workarounds, and those workarounds will be worse than whatever you were trying to replace.

The Only Metric That Matters Early On

Forget deployment frequency dashboards and adoption funnels. Early on, there’s one question: would engineers choose your platform if it wasn’t required?

If the answer is no, you have a product problem, not an adoption problem. No amount of migration mandates or executive sponsorship fixes bad developer experience.

Ship Small, Listen Hard

Start with the most painful thing. Fix it. Ship it. Watch what happens. Then find the next most painful thing. That’s it. That’s the strategy.

I’m three weeks into the founder-program cohort now, starting my infrastructure startup from scratch. Even at this stage, with just me writing the code, I’m thinking about what “the default path to production” looks like. Not because I need a platform. Because the habits you set in week one calcify fast, and undoing bad tooling decisions at 20 engineers is a nightmare I’ve already lived through while scaling an engineering team .

Build for the workflow your team already has. Then make the default path undeniably better.