You built the internal tool six months ago. It solved a real problem. Engineers loved it. Then the person who built it moved to a different team, and now it's a haunted house — everyone knows it exists, nobody wants to touch it, and the workarounds are multiplying faster than the documentation.
This is the hidden cost of custom internal tooling that never shows up in the build-vs-buy analysis. Not the engineering hours to build it. The organizational debt that accumulates the moment you ship it.
I wrote about the ownership dimension of build decisions back in June — the argument that what you're really deciding is who carries the thing forward, not whether the engineering is tractable. The sources I've been reading since then sharpen that point considerably. The failure mode isn't usually the initial build. It's what happens to the tool after the person who understood it stops caring about it.
The Maintenance Trap Closes Slowly
Braden Koh at CodedShapes tells a story that will be familiar to anyone who's managed a team with internal tooling. A senior engineer builds a spreadsheet-based workflow that cuts a three-day task down to four hours. It's genuinely good. Then requirements change, the tool doesn't keep up, and a new hire starts building a replacement because she can't get the original to work. The cycle resets.
The structural problem Koh identifies: maintaining the tool isn't in anyone's KPIs. It won't get the original builder promoted. It can't be justified on a Tuesday when there are deadlines. So it doesn't happen — not because anyone made a bad decision, but because the incentives never pointed toward maintenance in the first place.
The longer version of this plays out over years. Koh documents a fabrication company that built an internal tool a decade ago that genuinely transformed their delivery speed. Over time, the company expanded from one product line to five, adopted new processes, and started taking on more custom client work. The tool never kept up. By the time they wanted to migrate it to a modern platform, it was full of hard-coded variables, deeply entangled with old processes, and effectively unmaintainable. The migration quote was expensive enough that they declined it. The tool that once accelerated everything now blocks the work they actually need to do.
That's the trajectory. Not a dramatic failure — a slow calcification.
The Commodity/Differentiator Line Is the Actual Decision
The framing that cuts through most of the noise here comes from Ciente's analysis of the build-vs-buy question: the relevant distinction isn't "can a vendor do this?" It's "is this a capability we need to own?"
Commodity capabilities — things your business needs but that don't set you apart — are poor candidates for custom builds. Buying a vendor solution for payroll or standard CRM functionality costs you nothing strategically, because the process itself isn't where your edge lives. Differentiator capabilities are different. If a capability shapes how you create value in ways your competitors don't, outsourcing it hands partial ownership of your competitive position to a vendor.
The catch, as Ciente notes, is that this line moves. Something that was a genuine differentiator three years ago might be table stakes now. And the misclassification is expensive in both directions: over-engineering things that didn't need to be custom, or outsourcing things that were quietly central to how you operate.
For internal tooling specifically, most teams build when they should buy because the initial problem feels unique. The deployment pipeline has quirks. The data model doesn't match any vendor's assumptions. The workflow is genuinely specific to how this team operates. All of that may be true — and none of it answers the question of whether the capability is actually a differentiator or just a local constraint that a vendor solution could accommodate with some configuration.
The Question to Ask Before You Start
LinearB's analysis of engineering metrics tooling makes a point that generalizes well beyond their specific domain: the initial build is often the easy part. Standing up a basic dashboard takes a weekend. What breaks in month two is the data infrastructure underneath it — identity resolution, API maintenance across multiple tools, edge cases that accumulate as the organization changes shape. The visible artifact is tractable. The operational model required to keep it defensible over 18 months is the actual cost.
That's the question worth asking before any custom internal tool decision: not "can we build this?" but "what does it cost to keep this accurate and maintained as the team and the codebase change?" If the answer is "someone's discretionary time," you already know how it ends. Discretionary time is the first thing that disappears when a deadline moves.
The build-vs-buy decision for internal tooling is really a question about what you're willing to staff. If you're not willing to assign someone ownership — real ownership, with it in their scope and their performance review — then you're not building a tool. You're building a liability with a six-month fuse.