The reversibility curve: Why build vs buy gets harder the longer you wait

According to Exclaimer's research, 71% of in-house IT tools eventually get abandoned. The bigger waste is what comes before that point: years of maintenance work that quietly piles up while the tool is still in use. 

Internal builds rarely die dramatically. Maintenance hours creep up over months, and one Monday, a database team realizes it's spending half a working day patching reports for a billing system that should have been retired three years ago. By then, the tool is too embedded to remove without a project of its own. 

That pattern was the central thread of "Why build vs buy decisions get harder over time," a recent webinar conversation between Jeff Grettler, Head Brand Ambassador and Content Creator at Spiceworks Ziff Davis, and Karl Bagci, Director of IT and Information Security at Exclaimer. Karl's argument was simple. Build vs buy is a timing question, and the window for making the call doesn't stay open for long. Here are the key takeaways. 

The reversibility curve 

Early build decisions are cheap to reverse. The cost of changing course rises quickly as a tool accrues dependencies and embeds itself in everyday operations. 

Karl described this idea as the reversibility curve. A custom monitoring stack hand-rolled in 2013 looks like a quick win on day one. By year three, it sits at the center of the infrastructure, dependent on custom integrations and on a single engineer who remembers how the cron jobs hang together. Replacing it stops being a project and becomes a migration. 

Karl shared an example from a previous role. His database team was spending half a working day, every day, fixing broken reports out of a hand-built billing system. Removing it would have required a major investment of time and money. Keeping it required a smaller investment forever. By the time the cost of the build was obvious, the cost of unwinding it was already prohibitive. 

Jeff added the sysadmin's version of the same problem. There's always one server in the rack that nobody touches, because nobody remembers what depends on it. By the time the team agrees the tool should go, replacing it costs more than it ever did. 

The hidden cost is time 

A license fee is the easy number to compare. The harder number is the maintenance hours an internal build consumes once it's running, and what those hours could have been doing instead. 

Exclaimer's research, based on a survey of more than 2,000 IT and security leaders, lines up with that experience. 63% of respondents spend between 10 and 50 hours a month maintaining self-built tools. Two-thirds spend between $20,000 and $100,000 a year on maintenance alone. Only 8% of internal builds finish on time. None of those numbers tend to appear in the original business case. 

The bigger risk is people. Karl called accountability and documentation the most under-discussed parts of any build decision. A tool built by one engineer in 2022 might still run perfectly in 2026, until that engineer leaves and nobody else knows the codebase. Setting ownership at the start matters more than most teams give it credit for. The tool is already a future problem if nobody is named to maintain it or to take the 2 a.m. Sunday call when something breaks. 

Vibe coding is making the slope steeper 

AI-assisted development has lowered the barrier to building. It has also widened the gap between the people who can build and the people who know what good looks like. 

Vibe coding and low-code platforms have made the build option more accessible than ever, and not only for engineers. The complication, Karl said, is that the people building aren't always the people thinking about basic security hygiene. Basic questions about where data lives or what happens when a tool connects to a system holding sensitive customer data don't always make it into the build. 

Karl's team has started running vibe-coded apps through the same software development life cycle as production code, with review and code scanning before they reach production. The intent is to keep the speed advantage while limiting long-tail risk. Karl said the same picture emerged from a recent conversation with a CISO group: nobody has a confident answer for governing this yet. 

Making the case for an off-ramp 

Most build vs buy conversations are won or lost on translation, not technical merit. Quantifying the cost of inaction is usually the missing part. 

A CFO doesn't want a breakdown of why a legacy system is fragile. They want to know what happens to the bottom line if it fails, and what the financial exposure looks like if nothing changes over the next three to five years. The most overlooked half of that conversation, Karl said, is the cost of inaction. IT teams are good at quantifying the risk of changing something. They're less practiced at quantifying the risk of doing nothing. Both numbers belong on the table. 

Karl closed with a line worth carrying into 2026 planning. Optimize for keeping your options open as long as you can. That doesn't mean defaulting to buy. It means treating every internal build as a decision you'll need to revisit, and planning the off-ramp before you need it. Abandoning a half-built tool can be a reasonable response to better information. 

Convenience, as Karl put it, becomes more valuable as your career progresses, and the same applies to IT functions as they mature. 

Where this lands for email signature management 

The same pattern shows up in everyday IT functions, including email signature management. What starts as a quick PowerShell script becomes a fragile dependency that nobody wants to own. 

Exclaimer is the global leader in email signature management for Microsoft 365 and Google Workspace, trusted by more than 75,000 organizations worldwide, including Sony, Bank of America, the BBC, and the Academy Awards. With over 20 years of expertise, Exclaimer's cloud solution takes the admin off IT's plate by centralizing email signature and video meeting branding management across every user and device, with policy applied automatically and updated in real time. 

For IT teams already on the build side of the curve, the practical question is one of timing. The further an in-house solution drifts, the higher the cost of replacing it gets relative to the cost of maintaining it. 

Watch the webinar on demand 

The full conversation covers the reversibility curve in practice and how AI is reshaping the build vs buy decision. 

Watch the webinar on demand for the full session, including Karl's reasoning on why most build decisions can be reversed cheaply if you act early, and what it costs to wait.