Anna Totterdell
Projects Director
Nobody builds in-house because they want a mess. They build in-house because the outside quote looked eye-watering, or because the internal developer is genuinely capable, or because a director spent a weekend with a new tool and thought "surely we can wire this up ourselves," or because the business really does have a culture of shipping things.
Those are all rational reasons. The mistake is measuring the decision purely on the cost of the build.
The invoice the finance team sees
Hours. Tooling. A bit of cloud. Perhaps a contractor for four weeks. It fits neatly in a budget line and looks responsible next to the alternative.
The invoice that quietly arrives later
Think of what follows as five taxes that never appear on a purchase order, but always get paid eventually.
The first is ownership. Not who built the thing on day one, but who is accountable on day two hundred. Who handles the vendor API change. Who answers when an auditor asks how customer data moves between systems. Who decides what a safe change window looks like. If the honest answer is "whoever happens to have time," that is not ownership, that is a rota of guesswork.
The second is continuity. People move on. Priorities shift. The person who built the tool gets promoted into a role without any slack to maintain it. The documentation was "in Slack" and is now archaeology. Internal tools tend not to fail dramatically. They keep running until they do not, and by that point the one person who understood the edge cases is on a different project or at a different company.
The third is integration. The hard part was never really the script. It was the assumptions the script was making about other systems. Two systems disagree about what a customer record is. A date format drifts. A webhook fires twice. A nightly job overlaps with a manual upload at month-end. Somebody fixes a symptom upstream and now two corrections cancel each other out. Each incident looks minor on its own, which is why the pattern is missed until it is expensive. This is exactly what happens when data and systems integration is treated as glue between systems rather than as an explicit contract between them.
The fourth is attention. When a critical workflow depends on an informal internal tool, leadership becomes the backstop for anything that surprises it. That is a cost even when nobody invoices for it, and it lands disproportionately on the people who are already fully committed.
The fifth is compliance, and it only applies if the business operates under a standard - ISO 9001, ISO 27001, SOC 2, an FCA or NHS regime, a regulated product safety file, or any framework that obliges you to prove how your service is delivered. In that context, an informal tool touching service delivery is not just technical debt. It is an undocumented, uncontrolled, unvalidated system sitting inside what is supposed to be a managed environment. Your auditor does not care whether a human or an AI wrote the code. They care whether the tool is owned, changed under control, and reproducible. The cost shows up as a nonconformance in your next surveillance visit, and that one is genuinely hard to retro-fit under time pressure.
Why "just hire a firm" is not the answer either
Bringing in outside help is not a cheat code. Bad delivery is still bad delivery, regardless of whose logo is on the slide deck.
The argument is not that external is good and internal is bad. The argument is that a serious specialist engagement, done properly, forces a set of things to exist that internal teams often skip because nobody explicitly paid them to do it - a clear scope, test evidence that matches how the business actually runs, handover artefacts people can use, and a defined route for future change.
That is what tech consultancy is meant to deliver when the word is used honestly. Not a roadmap deck and some opinions, but independence, judgement, and accountability for production outcomes rather than for sprint velocity.
A more honest decision frame
If you are going to build internally, budget for the whole thing. That means monitoring. Runbooks. Access reviews. Regression tests for the moments when upstream systems change underneath you. And a named senior sponsor who can stand behind the tool for at least twelve months, not just the launch week.
If you cannot name those owners with a straight face when someone asks, you are not saving money. You are borrowing it on terms you have not read.
The practical close
Sometimes internal is the right answer. Sometimes it is the right answer for a first version and the wrong answer to leave alone for three years.
The businesses that end up in trouble are almost never the ones that built quickly. They are the ones that shipped a dependency into a core workflow and then never funded the maintenance, the governance, or the IT and process strategy that turns a working tool into an operation the business can actually rely on.
If you want one sanity check before committing, ask it plainly: who is accountable for this on day two hundred, not who is enthusiastic on day two?
