Why Organisations Keep Using Their Own Terrible Software (And How to Stop)

Mandating the use of a clunky internally developed software tool when a better, cheaper commercial alternative exists is a textbook case of the sunk-cost fallacy — and it is costing your organisation money, staff morale, and the productivity gains you almost certainly claimed in a business case somewhere. The fix is not technical. It is psychological, political, and occasionally requires someone to say something awkward in a room full of people who helped build the thing.

This piece is for the technology leader, programme director, or senior manager who suspects their organisation is doing exactly this — and wants the language, the evidence, and the argument to do something about it.

What Is the Sunk-Cost Fallacy, and Why Does It Thrive in Enterprise Tech?

The sunk-cost fallacy is the tendency to continue investing in something simply because you have already invested in it — even when the rational decision is to stop. In economics, sunk costs are costs that have already been incurred and cannot be recovered. The rational actor ignores them. The rational actor, in my experience, is rarely in the room.

In enterprise technology, the sunk cost often takes the form of an internally developed software system. It was built at considerable expense, possibly over several years, by a team of well-meaning developers who were told to solve a problem that a commercial product could have solved for a fraction of the cost — had anyone thought to look.

The fallacy kicks in at the moment someone suggests replacing it. Suddenly, the conversation is no longer about what the organisation needs. It becomes about what the organisation has already spent.

Why is internal software particularly vulnerable to this trap?

Commercial software is easy to evaluate against alternatives because it has a price tag, a vendor, and a marketplace. Internal software has none of these things. It has a history, a team, and — critically — people whose professional identity is tied to its existence.

That makes it almost uniquely difficult to retire, regardless of how bad it actually is.

How Do You Know If Your Organisation Is Doing This?

In my work across public sector and third sector organisations, I have encountered a fairly consistent set of symptoms. They are worth naming clearly, because individually they each sound reasonable. Together, they paint a different picture.

The tool has a dedicated internal support function that exists solely to compensate for the tool's inadequacies.
Staff have developed elaborate workarounds — usually involving spreadsheets — to do things the tool was theoretically designed to do.
"We've always done it this way" is offered as a feature, not a flaw.
New starters regularly flag that the tool is inferior to what they used in previous roles, and are gradually worn down until they stop mentioning it.
The commercial alternative is demonstrably cheaper, better-supported, and more frequently updated — and nobody disputes this — but the conversation always ends with "but we've invested so much."
Any proposal to switch is described as "a big change" in a tone that suggests the word "big" is doing a lot of heavy lifting.

If three or more of those feel familiar, you are almost certainly dealing with a sunk-cost situation dressed up as a strategic decision.

What Does This Actually Cost?

This is where the argument tends to get uncomfortable for the people defending the status quo, because the costs are real and they compound.

Direct costs

Internal software requires ongoing maintenance, infrastructure, licensing of underlying components, and developer time for every update. A 2023 Gartner analysis found that organisations typically spend 70–80% of their IT budget on "keeping the lights on" rather than innovation — and legacy internally built systems are a significant contributor to that ratio.

The commercial alternative, by contrast, spreads those maintenance costs across thousands of customers. You are, in effect, paying a proportional share of a much larger engineering team.

Indirect costs

These are harder to quantify and therefore easier to ignore, which is precisely why they tend to be ignored.

Productivity loss: Staff using inferior tools work more slowly and make more errors. The McKinsey Global Institute estimated that employees spend an average of 1.8 hours per day searching for and gathering information — much of that friction is tool-related.
Recruitment and retention: Talented people — particularly in technical roles — notice when an organisation uses bad tools and treats that as a red flag about the organisation's judgment.
Opportunity cost: Every hour your developers spend maintaining the old system is an hour not spent on something that actually moves the organisation forward.
Strategic drift: Organisations anchored to internal tools often find their processes shaped by the tool's limitations rather than their actual needs. The tail wags the dog, quietly, for years.

The Classic Defences — and Why They Don't Hold Up

I have sat in enough rooms where this argument plays out to have memorised the script. Here are the most common defences of the clunky internal tool, and what is actually being said.

"We've built up years of institutional knowledge in this system."

What this means: the system has accumulated workarounds, undocumented behaviours, and tribal knowledge that would be painful to migrate. This is a real concern. It is not, however, a reason to keep the system. It is a reason to invest properly in a migration — which is a one-time cost, not a permanent liability.

"The commercial alternative doesn't do everything our system does."

This is almost always technically true and strategically irrelevant. Most of the things your internal system does that commercial alternatives don't are things you shouldn't be doing anyway — or things you built to compensate for a process problem that also needs fixing. A commercial tool that covers 85% of your needs and is actively developed is usually a better long-term bet than a bespoke system covering 100% of a process that was designed in 2011.

"We'd lose control of our data."

This concern is legitimate and deserves a serious answer — which reputable commercial vendors have been providing for years through data processing agreements, ISO 27001 certification, and robust contractual protections. It should be evaluated properly, not used as a conversation-stopper.

"We've invested too much to walk away now."

And there it is. This is the sunk-cost fallacy in its purest form. The money is gone. It left the building. The only question now is whether you want to keep spending money on a system that isn't good enough, or spend money on one that is. Those are the only two options. The past is not one of them.

Internal Build vs. Commercial Off-the-Shelf: A Straight Comparison

Factor	Internally Built Tool	Commercial Off-the-Shelf (COTS)
Initial cost	High — development, architecture, project management	Low to medium — licensing, implementation, configuration
Ongoing maintenance cost	High — your team, your infrastructure, your problem	Shared — spread across vendor's entire customer base
Feature development	Depends entirely on your internal capacity and backlog	Continuous, driven by vendor investment and market competition
Security updates	Your responsibility; often delayed or deprioritised	Vendor responsibility; typically regular and contractually assured
Integration ecosystem	Custom-built; bespoke APIs; often undocumented	Pre-built connectors; standard protocols; community support
Talent dependency	High — knowledge often held by a small number of individuals	Low — skills transferable across organisations
Scalability	Requires significant architectural investment	Typically built-in; vendor's problem to solve
Customisation	Theoretically unlimited; practically constrained by capacity	Configuration within vendor parameters; extensible via APIs
Risk profile	Concentrated — vendor is you; bus factor is real	Distributed — vendor risk; contractual protections available
User experience	Variable; often deprioritised in favour of functionality	Typically higher; UX is a commercial differentiator for vendors

There are scenarios where building internally is the right call — genuinely novel problems with no commercial equivalent, or where a core competitive advantage depends on proprietary tooling. A standard HR system, CRM, project management tool, or document management platform is almost never one of those scenarios.

So When Does Building Internally Actually Make Sense?

It is worth being fair here, because the argument is not that internal development is always wrong. It is that mandating the continued use of an inferior internal tool out of inertia is always wrong.

Internal development makes sense when:

No commercial equivalent exists for a genuinely unique operational problem.
The tool is a core part of your competitive or strategic differentiation — and this is a real, defensible claim, not a rationalisation.
Data sovereignty or regulatory requirements genuinely preclude commercial solutions after proper evaluation (not just reflexive concern).
The commercial market is immature and the build-versus-buy calculus is genuinely uncertain.

None of these conditions describe most of the internal tools I have encountered. Most of the internal tools I have encountered were built because someone once decided to build them, and that decision calcified into policy.

How Do You Make the Case for Change?

The sunk-cost fallacy is not defeated with logic alone, because it is not a logical position. It is an emotional and political one. The argument has to work on both levels.

Step 1: Name the actual cost of staying still

Build a total cost of ownership (TCO) model that includes developer time, infrastructure, support costs, and — critically — a conservative estimate of productivity loss. Most organisations have never done this calculation honestly, because nobody who benefits from the status quo has been motivated to do it.

Step 2: Reframe the sunk cost explicitly

Say the words. "I understand we've invested significantly in this system. That investment is gone — we can't recover it by continuing to use the system. The question now is what we spend going forward, and on what." Some people need to hear this framed directly before they can engage with the substance of the argument.

Step 3: Run a proper market evaluation

A formal make-versus-buy assessment conducted transparently, against defined criteria, is much harder to dismiss than an informal comparison. It also provides cover for decision-makers who privately agree with you but need a process to point to.

Step 4: Pilot the alternative

If you can, run a limited pilot of the commercial alternative with a willing team. Real data from real users is worth more than any slide deck. People who have experienced the difference become advocates, and advocates inside the organisation are considerably more persuasive than an external consultant saying the same thing.

Step 5: Address the people question directly

The team who built and maintain the internal system have a legitimate stake in this conversation. Handled badly, a move to a commercial alternative feels like a verdict on their work. Handled well, it is an opportunity to redirect their skills to higher-value work. The transition plan must address what happens to the people, not just the platform.

A Note From My Own Experience

I have worked on digital transformation programmes where a significant portion of the "transformation" was, in practice, the painstaking process of convincing an organisation to stop using a system it had built in 2009 and replace it with something its staff had been quietly asking for since approximately 2013.

In one case, the internal tool had a dedicated team of six people whose primary function was managing the workarounds required to extract data from it into a format anyone could actually use. The commercial alternative — which cost less annually than two of those six salaries — imported the data natively. The transition took four months. The four months before the transition took two and a half years, because the conversation kept ending with "but we've invested so much."

I am not naming names. I am saying it is more common than anyone is comfortable admitting.

What About the Change Management Side?

Technology transitions that fail usually fail because of people, not platforms. This one has a particular human dimension because it involves retiring something that people built, and potentially redeploying or restructuring the team that maintains it.

The principles here are not complicated, but they do require consistent effort:

Communicate the why clearly and early. People can handle change much better when they understand the reasoning. What they struggle with is feeling like a decision was made about them without them.
Involve the internal development team in the transition. Their knowledge of the current system's quirks and integrations is genuinely valuable during migration. Give them a meaningful role rather than a watching brief.
Invest properly in training. A new tool that people don't know how to use is not an improvement. Training is not optional; it is the difference between adoption and shelf-ware.
Set honest expectations about the transition period. Things will be slower before they are faster. Build that into your planning rather than pretending it won't happen.

The Organisational Culture Question

The sunk-cost fallacy in technology is, at its root, a culture problem. Organisations that are good at making rational technology decisions have built a culture where it is safe to say something isn't working — and where the decision to retire a failing investment is treated as evidence of good judgment rather than failure.

Organisations that are bad at it have cultures where admitting a past decision was wrong feels like a personal attack on the person who made it. In those organisations, the internal tool survives not because anyone truly believes it is the best option, but because no one wants to be the person who says it isn't.

That is not a technology problem. That is a leadership problem.

Frequently Asked Questions

Is the sunk-cost fallacy always the reason organisations stick with internal tools?

Not always. Genuine data sovereignty concerns, regulatory constraints, or a lack of suitable commercial alternatives are legitimate reasons to maintain internal tools. The sunk-cost fallacy is at play specifically when the decision to continue is driven primarily by prior investment rather than current-state evaluation. If the honest answer to "why are we still using this?" is "because of what we spent on it," that's the fallacy.

How do you calculate the total cost of ownership of an internal tool?

A TCO model for an internal tool should include: developer salaries allocated to maintenance and support; infrastructure costs (hosting, licensing of underlying components); security and compliance overhead; the cost of incidents and outages; and an estimate of productivity loss from usability issues. Most organisations significantly underestimate these costs because they are distributed across multiple budget lines and never aggregated.

What if the commercial alternative doesn't do everything our internal system does?

It almost certainly won't — and it is worth asking whether everything your internal system does actually needs to be done. In practice, many bespoke features exist to support processes that are themselves suboptimal. A good implementation of a commercial tool is often an opportunity to simplify processes, not just replace technology. Evaluate the gap honestly: is it a genuine capability gap, or is it a reflection of something you've always done that you've never questioned?

How do we handle the team who built the internal tool?

With honesty and involvement. Talented developers who built your internal system have skills that are valuable regardless of whether the system survives. Give them a meaningful role in the transition — their knowledge of the current system's data structures and integrations is genuinely useful during migration. The worst outcome is for them to feel like observers of a decision being made around them. The best outcome is for them to become advocates for the new system because they were part of making it work.

What is the "bus factor" and why does it matter here?

The bus factor (sometimes called the truck factor) refers to the number of people in a team who, if they were suddenly unavailable, would put a project or system in serious jeopardy. Internally built tools often have a very low bus factor — sometimes one or two individuals hold critical knowledge about how the system works. That is a significant operational risk that rarely appears on risk registers but absolutely should.

Can you mandate adoption of a new commercial tool without generating significant resistance?

Mandate without engagement tends to generate exactly the resistance it is trying to bypass. A better approach is to build genuine demand for the change through pilots, early adopters, and honest communication — and then use mandate as a backstop rather than a first move. People who have seen the alternative work are far easier to bring along than people who are being told to change something that, from their perspective, mostly works fine.

Is this problem more common in the public sector?

In my experience, yes — though not for the reasons people assume. It is not that public sector organisations are less capable of making rational decisions. It is that the political and accountability structures around spending decisions make it genuinely harder to write off a past investment, even when doing so is the right call. There is also often a longer cycle between technology decisions and consequences, which means the full cost of the sunk-cost fallacy takes longer to become visible. The good news is that value-for-money frameworks in the public sector, applied honestly, provide a strong basis for making the case for change.

Nicholas Hodder is a digital transformation and technology leader with over 20 years of experience across public sector, charity, and commercial organisations. He speaks and writes about the gap between technology strategy and the reality of implementation — which turns out to be a very large gap with a great deal of interesting material in it.