Why Internal Developer Platforms Should Never Be Mandatory
I’ve had many conversations about Internal Developer Platforms (IDPs) and the broader concept of Platform as a Product. One topic that comes up more often than I’d like is the idea that a platform should be mandatory for developers. Management, in particular, often struggles with the concept of an optional platform. In their view, it’s the responsibility of the platform team to build the system, and the job of leadership to enforce its use. Because using the platform reduces cost
This mindset is flawed.
Forcing developers to use an internal platform is not only counterproductive but also goes against the very principles of a product-driven approach. Mandating usage removes incentive for innovation, reduces developer satisfaction, and increases the risk of shadow IT. Instead, the platform should be something developers want to use, not something they’re forced to use. Moreover, the main goal of the platform is to lower cognitive load and increase developer happiness. reducing cost is a consequence of doing things right.
In this post, I’ll share some key arguments in favor of making your platform optional—because an IDP that succeeds by choice is a far better investment than one that survives by decree.
1. A Platform Is a Product—And No Product Should Be Mandatory
Imagine if a company forced all its employees to use a specific brand of smartphone, regardless of their personal preferences or the specific needs of their role. Some employees might be fine with it, while others—who require different features, integrations, or workflows—would find it frustrating and limiting. The result? Reduced productivity, dissatisfaction, and, inevitably, people finding ways around the restriction.
A platform is no different.
A well-designed Internal Developer Platform is a product, and just like any good product, its success depends on adoption, not coercion. If no one wants to use your platform, that’s a sign that it’s not solving real problems. No one forced developers to use tools like GitHub, AWS, or Kubernetes—these products have won their place in the ecosystem by being useful, not mandatory. When developers choose to use a platform, it’s because it genuinely solves their problems and makes their work easier. If they avoid it, it’s not a problem with the developers—it’s a problem with the platform.
A true product-driven approach starts with understanding developers’ needs and building solutions that address their actual pain points. If developers willingly choose your platform, that means it’s providing value. If they avoid it, that’s a clear signal that something is wrong. As I always try to explain to people: We’re not doing IT for the sake of doing IT, IT should be used as an enabler for Business Value. Building a platform that doesn’t meet developer needs, is just IT for IT.
2. Adoption Through Choice, Not Force
People naturally resist being forced into something, even if it’s meant to help them. It’s a psychological reflex—when we feel like our autonomy is taken away, we instinctively push back. This applies to many aspects of life, and developer workflows are no exception. If an internal platform is imposed on developers with a top-down mandate, they’re more likely to find workarounds, resist change, or, in extreme cases, resort to shadow IT—where they build their own unofficial tools outside of sanctioned systems.
Forcing developers to adopt a platform often leads to begrudging compliance rather than genuine engagement. They’ll use it because they have to, but they won’t invest in it. They won’t contribute ideas for improvement, and they certainly won’t advocate for it to others. Instead, they might focus their energy on finding loopholes, questioning its value, or simply tolerating it as a necessary evil. This kind of “adoption” is brittle—it creates friction, frustration, and an eventual drain on productivity.
On the other hand, when developers have the option to use a platform, the entire dynamic shifts. A voluntary choice fosters genuine engagement. Developers who willingly adopt the platform will provide better feedback, experiment with new features, and even become internal champions who encourage others to try it. Instead of resistance, you get advocacy. Instead of shadow IT, you get constructive collaboration.
A well-designed platform doesn’t need enforcement—it wins adoption through merit. The teams that use it should do so because it makes their work easier, not because someone higher up decided it was mandatory. And when developers choose a platform voluntarily, that adoption is not only stronger, but also more sustainable in the long run.
3. Organic Growth and Sustainable Scaling
Building a one-size-fits-all platform for an entire IT organization is a massive challenge. When a platform is forced on developers, it creates an artificial demand that can overwhelm the platform team with support tickets, unexpected edge cases, and dissatisfaction.
A better approach is to start small. Begin with a few teams who want to use the platform and solve their specific problems. As those teams find value in the platform, adoption will naturally spread. This organic growth ensures that the platform evolves based on real needs, rather than theoretical requirements. From a management perspective this can be seen as optimal use of invested time and money. Rather then spending countless of hours on unnecessary details, we only invest time and money in what really matters saving some budget in the long run.
Additionally, by growing adoption organically, the platform team can mature at a sustainable pace, learning from early users and improving the platform iteratively—rather than being buried under a flood of feature requests and complaints.
A Platform That Developers Want to Use
A mandatory platform doesn’t guarantee success—it only guarantees compliance, and compliance without enthusiasm leads to resentment.
The best platforms are those that developers choose to use—not because they have to, but because it makes their lives easier. A well-designed Internal Developer Platform should be a tool that developers reach for voluntarily, not something they are forced to endure.
So, to management and platform teams out there: If your platform needs to be mandatory, ask yourself why. Is it because it’s solving real problems? Or is it because developers wouldn’t choose it otherwise? If it’s the latter, then forcing adoption won’t fix the issue—it will only hide it.
Great platforms don’t need mandates. They succeed because they’re valuable. Make your platform a choice, and you’ll build something that developers actually want to use. And that is the true measure of success.