Stuart Totterdell
Technical Director
Someone on your team spent a weekend wiring up a small automation. It works. The process it replaced used to eat half a day a week, and now it does not. Three months later, two other teams quietly start using it. Six months later, a client report depends on its output. A year later, nobody can remember exactly how it handles refunds, and the person who built it has moved to a different project.
That is not a story about bad engineering. It is a story about a prototype that nobody decided was a production system - because the decision never felt like it needed making.
I want to say something you do not often hear from a firm that sells delivery work: sometimes the right answer really is to build it yourself. A one-off script. A Zapier flow between two stable SaaS products. An internal tool with one owner and a ten-minute recovery plan that is literally "run it again." If the blast radius is small and nothing important breaks when it breaks, a specialist engagement would just add cost and ceremony.
The thing to be honest about is what happens when the tool stops being small.
What has genuinely changed
The first eighty percent of many automations got dramatically cheaper in the last two years. You can sketch the problem in plain English, get working code back, wire a couple of APIs together, and demo it by the end of the afternoon. That is real progress, and it is why "we can do that ourselves" now comes up in more sales conversations than it used to.
That sentence is usually true for the demo. It is less often true for month twelve, because the demo was never the expensive part.
The bit nobody wrote down
A production automation is only the script in the same sense that a car is only the engine.
It is also what happens when the ERP patch quietly renames a field. When the person who "just knows" how refunds work goes on parental leave. When the same customer is stored in three systems with three different spellings. When a webhook arrives twice. When a nightly job overlaps with month-end close because nobody told it not to. It is retries, idempotency, dead-letter queues, monitoring, access control, and a clear answer to "who looks at this when it silently stops working on a bank holiday?"
A vibe-coded prototype handles the happy path well. The unhappy paths do not show up until volume, time, and real data arrive, and by then the tool is already load-bearing.
None of this is an argument against your team experimenting. It is an argument for honesty about what you have actually committed to when something built on a Tuesday starts running a multi-team workflow by Friday.
When DIY is genuinely the right call
Keep it in-house when most of these are true.
The workflow touches one team. The data is low-sensitivity. There is a named person who enjoys maintaining it. An hour of downtime creates inconvenience, not loss. You could switch it off tomorrow and nothing would need a migration plan.
In that situation, speed wins. The calculation is simple, the risk is contained, and the business gets a small, real improvement without anyone needing a steering committee.
When DIY quietly becomes debt
The line gets crossed the moment any of these are true.
Multiple teams depend on the output. Money moves, inventory moves, or a customer promise is on the other side of it. The tool sits between systems whose roadmap you do not control. Business logic has started living in a spreadsheet next to the automation, because nobody wanted to touch the automation. The work forms part of a service your business is held to evidence under a compliance standard - ISO 9001, ISO 27001, SOC 2, an FCA or NHS framework, or any regime that obliges you to describe how things are produced. Nobody has written down the failure modes, because everybody assumed the happy path was the whole path.
That is the point where you are no longer saving money. You are deferring cost into incidents, rework, and leadership attention - usually onto the people who were already the bottleneck before the tool existed.
This is where tech consultancy stops being a pitch phrase and starts describing a specific kind of work: turning something fragile into something the business can operate, audit, and hand over without holding its breath.
Before any more code is written on top, someone needs to answer a blunter question: what does "good enough to run the business on" actually look like for this workflow? That is IT and process strategy work, not governance theatre.
The question worth asking out loud
If the internal build is already in production, skip the blame and ask one thing.
If the person who wrote it handed in their notice on Friday, what happens on Monday?
If the honest answer is "fine, the documentation is current and someone else can pick it up," you probably made the right call. If the honest answer is a shrug and a hope, the tool is not an asset. It is a dependency dressed up as progress, and the longer that continues the more it costs to fix.
The point
There is no moral argument against internal builders, and we are not making one. The pattern we keep seeing is not that businesses built the wrong things. It is that cheap prototypes became unowned production systems, because nobody at the time priced what it takes to own one.
Once the blast radius is real, the job stops being code and starts being business automation as a discipline: scope, evidence, a test plan that reflects reality, a named owner, and an answer for when things break.
If you are not sure which side of the line a current tool sits on, that is not a failing. It is the right moment to get a second pair of eyes before it hardens into something awkward to unwind. Almost every expensive story of this kind starts with the same sentence: "it was only meant to be temporary."
