Stuart Totterdell
Technical Director
If your team can genuinely build it, you should genuinely consider building it.
That is not a sentence that makes me popular in every sales room, but it is still true for the right shape of problem. The failure mode I keep seeing is not that businesses built their own automation. It is that they built it without ever deciding what they were actually signing up for.
So before telling a client to go internal, hire us, or pause entirely, I ask three questions. There is no theatre to them. The answers usually decide the conversation before any proposal is written.
Question one: what is the blast radius if this is wrong for forty-eight hours?
Not wrong forever - wrong briefly. A quiet duplication. A half-completed sync. A transformation that rounds the wrong way. A workflow that pauses at step three and nobody notices until the next morning.
Who feels that first? How many teams are affected? Does money move during those forty-eight hours? Does stock move? Does a customer see something they should not? Does anything regulatory get touched?
If the honest answer puts the blast radius at the wider end, the question on the table is no longer whether to write some code. It is whether to run a production-grade system without production-grade habits around it.
A wide blast radius does not automatically mean hiring a firm. It does mean budgeting for what has to sit around the code regardless of who writes it - proper tests, monitoring, a named owner, a change window, a rollback plan. If none of those can be funded or staffed internally, the build is not affordable, no matter how quick the first sprint looked.
Question two: who owns it on day two hundred - a name, not a team
Teams are not owners. People leave. Reporting lines change. Roles are not answers, because a role cannot be the person who says no to feature creep, or the person who handles a vendor API change at short notice, or the person who sits with finance when they want to know how a number was produced.
If a name does not come to mind within a few seconds, there is no plan for ownership. There is a hope that whoever was enthusiastic at the start will still be enthusiastic in nine months' time, which is not a hope that ages particularly well.
This is the point where IT and process strategy stops being a deck and starts being operational. Strategy in this context is whoever has the authority to maintain coherence when reality stops cooperating with the plan.
Question three: what evidence will you accept that it is correct before go-live?
If the only evidence is "it looked fine in testing," the business is gambling.
Real evidence has a shape. It might be reconciliation totals between two systems. It might be row-level sampling against a trusted source. It might be a parallel run for a fortnight. It might be a well-defined UAT window with formal sign-off from the team that will have to live with the outcome afterwards. The specific choice matters less than its existence, and the rigour should be proportional to the blast radius established in question one.
If no form of evidence can be defined, the project is not ready to go live. Not morally - practically. There is nothing to prove it is correct, and the first time it is wrong will be the first time anyone looks properly.
This is where external delivery sometimes earns its place, not because outside teams are inherently cleverer, but because an external engagement tends to force evidence artefacts into existence that internal teams skip when nobody is explicitly paying for them.
A tech consultancy engagement can be bought narrowly for exactly that reason - a short, hard-edged readiness review, rather than a full build, when what the business actually needs first is an independent verdict.
A fourth question, if the business is regulated
The three questions above apply to every internal build. If your business is held to a compliance standard - ISO 9001, ISO 27001, SOC 2, an FCA or NHS framework, or any regime that obliges you to describe how a service is produced - add one more.
If an auditor or a customer asked you to walk through exactly how this tool works, who owns it, who approves changes to it, and how you know its output is correct, could you answer with evidence rather than with confidence?
If the answer is yes, the tool is already inside your management system and the build can proceed like any other. If the answer is no, what you have is shadow IT with a friendly name. The standard does not object to AI-assisted code, and it does not object to internal tooling. It objects to uncontrolled software of any origin sitting inside a managed environment. A build that cannot survive that one question is not cheaper than a build that can - it is the same cost, deferred until the next surveillance audit.
What happens after the answers
If the answers are strong and the blast radius is small, the right recommendation is to go ahead internally. Speed genuinely wins.
If the answers are weak, the right next move is almost never a full statement of work. It is usually a narrower scope, a reduced blast radius, or a short discovery phase that produces a current-state map and a test plan. Business automation that survives contact with the real business is, in practice, a preparation problem more often than it is a delivery problem.
The close
These questions are not a trap, and they are not rhetoric. They are the quickest way to avoid spending money on the wrong version of the problem.
Passing all three cleanly means building with confidence. Failing them honestly means failing cheaply, on a whiteboard, rather than in production at month-end. Failing them and building anyway usually means talking to us later - on worse terms, under pressure, after something important has gone quietly wrong overnight.
The whiteboard conversation is the one worth having first.
