We all build internal tools to save time, right? But I’m tracking a trend where engineering teams are spending 10-15% of their sprint maintaining, debugging, or onboarding new hires to custom, “simple” internal tooling. When does the complexity tax outweigh the benefit? What’s the hidden cost of the tools you had to build, versus what you bought?
10-15% feels low. We had a guy whose entire job was patching the custom deployment pipeline built by an intern in 2019. It wasn’t simple, it was just undocumented. We basically hired a full-time maintainer for a tool that saves us maybe 4 hours a week
It’s not just about time. Control matters. The moment you rely on a vendor, your roadmap is at their mercy. That 10% maintenance is the price of keeping the keys to the kingdom. We build the core stuff; we buy the peripheral stuff.
It’s a résumé problem. Engineers build ‘cool’ bespoke systems because it looks better on a CV than ‘I integrated Stripe and leveraged AWS Managed Services.’ Complexity is job security, disguised as optimization.
Been there. The tipping point is usually around employee number 50. Before that, custom tools are efficient tribal knowledge. After that, they become a liability. You need to enforce a build vs. buy framework that factors in onboarding time and migration risk, not just immediate dev effort.