Quick take
Stop building internal platforms nobody asked for. Talk to your engineers first. If they’d rather copy-paste bash scripts than use your platform, that tells you everything.
I’ve built internal tooling at three companies now. The fintech startup, Dropbyke, and most recently the early groundwork at Decloud. Two out of three times, I got it wrong.
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, Not Infrastructure Projects
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 Dropbyke, I finally learned this. 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.
Golden Paths, Not Golden Cages
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 EF batch now, starting Decloud from scratch. And even at this stage – just me and a co-founder – I’m thinking about what “the default path to production” looks like. Not because we 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.
Build for the workflow your team already has. Then make the default path undeniably better. Everything else is noise.