Forecast
Why the platform becomes a drawer eventually
Last year we spent three months implementing Backstage at my company. Had a consultant, the whole thing. Six months later, half the teams weren't using it. Not because it was broken—it worked fine—but because nobody actually needed it to do their job yet.
The thing people don't say out loud is that a developer platform only becomes valuable when the pain it solves is worse than the friction of adopting it. If your infrastructure is small enough that people just know how to deploy, or if you only have three services and they all work the same way, Backstage looks like work with no payoff. You're asking engineers to learn a new UI to do something they already do via muscle memory. That's a losing trade.
What actually happened to us: we had maybe two teams that faced genuine complexity—service discovery, deployment targets, secret rotation—and for them the platform was immediately useful. The rest stayed in Slack, keep using the same scripts, kept doing deploys the way they always had. The platform only becomes sticky when you've got enough services that the alternative (email chains, outdated wikis, asking someone in Slack who's the expert on the auth service) becomes genuinely intolerable. Before that threshold, it's overhead.
I'd bet most platforms fail not because they're bad but because they get funded before the company is actually large enough to need them. You build it to solve problems you'll have at scale, then discover you're only at scale *somewhere*—and the teams that aren't at scale yet just see extra buttons. The ones that survive usually get some forcing function: a security incident that makes you care about secrets management, a deployment outage that makes discovery matter, an on-call rotation that gets painful enough that automation becomes worth learning. Those drive adoption because the pain is real and immediate.
3 comments
Log in to comment.
We hit this exact wall at my last job, except we found it out the hard way. Built an internal platform team, hired someone to lead it, spent a quarter designing this beautiful service catalog. Then we realized: we had twelve services total, owned by four teams, and everyone already knew where everything was. The catalog sat at like 20% fill rate for months because the people who'd use it most—senior engineers—already had mental maps that were faster than typing into a UI.
What actually moved the needle was when we got acquired and suddenly had to integrate their infrastructure. Forty new services we didn't own, deployment patterns we'd never seen, secrets scattered across three different vaults. The platform went from "nice to have" to "we literally cannot onboard people without this" in about two weeks. Adoption was instant. But I'll be honest—if we'd stayed independent, we probably would've killed the project and called it a loss.
The sting is that the work wasn't bad. The person we hired was good. But the insight in the post is right: you're solving for a future scale state and asking everyone to pay the tax now. In a twelve-service world, that tax is real and visible. At forty services, it's invisible because the alternative is chaos. The problem is knowing which world you're actually in when you're deciding to build something.
You're naming something real here that most platform retrospectives dance around. The adoption problem isn't really an adoption problem—it's a timing problem. You built the right tool for the wrong maturity level of the organization, which is a much harder thing to avoid than shipping buggy code.
The part that lands for me is the threshold insight. I've seen this play out differently at different companies, but the pattern holds: at my last job we had a similar thing with a service mesh. Teams running five services thought it was theatre. Teams running thirty with complex routing needs found it indispensable within two weeks. Same tool, wildly different reception depending on whether the underlying problem actually existed yet for that team. The mistake was treating adoption as a binary company-level decision when it was really a per-team readiness question.
Where I'd push back slightly: some of the platforms that did stick around weren't waiting for a crisis, they just got lucky with an early win from a team that *was* at scale, and that credibility bootstrapped broader adoption. Slack's API platform is the obvious example but closer to home, we had one engineer who built a deploy dashboard that solved a real problem for one team doing frequent releases, and that created enough internal buzz that other teams started experimenting. It became harder to ignore once some group was clearly faster than everyone else. I think you're right that pain is the most reliable forcing function, but sometimes just having visible winners can create enough friction (in the right direction) that people start adopting before they strictly have to.
I think we're going to see a lot of these platforms quietly sunset in the next few years, and it won't look like failure—it'll look like "consolidation" or "we're using the 80% we need." Companies will have spent real money on Backstage or similar, the early adopter teams will still use it, and the rest will have drifted back to whatever worked before. The platforms that survive will be the ones that got *forced* adoption: Datadog because you literally can't operate without observability at scale, PagerDuty because on-call breaks if you don't have it, that kind of thing.
The forcing function angle is the one people miss. We tried rolling out our own thin platform layer about four years ago when we had maybe 15 services. Got maybe 30% adoption. Then we hit a deployment incident where nobody could tell what was running where, and suddenly everyone cared. But that doesn't scale as a growth strategy—you can't plan on incidents to drive adoption. So you get stuck choosing between forcing it top-down (which causes resentment) or letting it atrophy (which wastes the investment).
My prediction: the platforms that work will be the ones that solve a problem that's *already painful*, not the ones solving problems you think you'll have. And a lot of the ambitious ones will end up as a service catalog that five teams use while everyone else keeps their own dashboards.