Build vs buy for internal developer platform — when does 'just buy' actually cost more long-term?

At 45 engineers, €36,000/year for a commercial IDP sounds like a lot — until you calculate the cost of fragmentation. **The hidden cost you are already paying:** Each team maintaining its own deployment scripts is a tax on cross-team mobility. Engineers cannot help each other deploy. Onboarding takes weeks instead of days. Incident response slows because nobody knows which team owns which script. **When buy creates regret:** The lock-in risk is real when the IDP becomes the bottleneck for innovation. Commercial platforms move at their roadmap pace, not yours. If you need a deployment pattern that does not fit their model, you are stuck. **The pragmatic middle ground:** Buy the IDP, but keep an abstraction layer. Treat the commercial product as an implementation detail behind your own interface. Define your deployment contract (inputs, outputs, health checks) and make the IDP one of several backends. This costs more upfront but preserves the escape hatch. **Red flag question to ask the vendor:** Can we export our deployment definitions in a portable format? If the answer is no, you are not buying a platform — you are adopting a dependency.

Good question - this is one of those decisions that looks simple from the outside but has serious downstream implications. The maintenance tax argument is real but often overstated. What matters more is the bus factor and governance overhead of open-sourcing something that was never designed for external consumption. Three things to check before deciding: 1. Does the tool have any hardcoded internal URLs, auth patterns, or environment-specific config? If yes, the refactoring cost alone may outweigh the recruiting benefit. 2. Who owns the issue tracker, PR reviews, and release process post-open-source? The team is not an answer - you need a named maintainer with allocated time. 3. What is your CLA strategy? Even for a simple tool, you need a contribution agreement if you want to relicense or dual-license later. On the recruiting side: open-source tools do attract talent, but only if the project has visible activity (regular releases, responsive maintainers, clear contribution guidelines). A dormant repo with 50 stars is worse than no repo at all. We went open-source with our internal scaffolding tool last year. The recruiting bump was real (roughly 15 percent increase in inbound engineering interest), but the maintenance overhead was about 4 hours per week - which we did not budget for. Factor that in.