Stuart Totterdell
Technical Director
Strip the marketing out of what firms like ours do, and the job comes down to a single sentence.
We reduce operational risk in the places where the business has been quietly paying for it - in time lost, errors made, and hours of senior attention spent on problems that should never have reached that level.
Clients often translate that back to us as "you sell integrations and scripts." That is an understandable shorthand. It is also incomplete enough to cause the wrong firm to be hired for the wrong reason, and it is usually why buyer's remorse happens on engagements that technically delivered what was on the page.
What follows is the literal list of what a serious engagement is trying to produce. Not a philosophy - deliverables.
A scope sentence that survives pressure
If the outcome cannot be stated in a single, tight sentence, the scoping work is not finished.
Not a theme. Not "automation across the finance function." A sentence a CFO could repeat in a board meeting without wincing.
That sentence is itself a deliverable. It prevents scope creep. It stops the team automating the wrong thing beautifully. And it gives the buyer a genuine basis for comparing two proposals, rather than comparing two different interpretations of the same broad idea.
A current-state map grounded in evidence
This is not a generic process diagram drawn from a distance. It is the actual path - the systems, the handoffs, the exceptions, the workarounds - captured from the people who do the work every day, rather than from the version of the process that lives in a policy document.
It is the document that prevents the late, expensive surprise when automation meets reality and reality quietly wins.
A test plan that matches how the business actually runs
Happy-path tests are necessary and they are never sufficient.
A serious plan includes exception routes, reconciliation rules, volume assumptions, and a parallel-run or shadow period when the stakes require it. If there is no test plan, there is no serious business automation engagement underneath. There is only a build with a bow on it.
Integration behaviour that is explicit, not assumed
The contracts between systems are where "it worked in the demo" tends to die.
A good engagement writes down what "correct" means when two systems disagree on a value. It writes down the retry and idempotency rules where they matter. It writes down what should happen when a vendor sends duplicates, or empty fields, or files that arrive late.
This is what data and systems integration should actually mean when it appears on a proposal - not the movement of payloads, but a clear definition of behaviour under failure.
Observability, and a named owner
Someone has to know the thing failed before the business stumbles onto it by accident. Someone has to be able to trace a single transaction across every step it takes. And someone has to know what "normal" looks like in the logs well enough to notice when it is not.
If the engagement ends at "it is deployed," what was bought was a launch, not an operation.
A handover that survives the real organisation
Handover is not a folder of PDFs.
It is training sessions. Walkthroughs. Documented change procedures. And a named internal owner who has already made a safe, routine change while the external team was still standing nearby, so that the first change they make alone is not a stressful one.
If the internal owner cannot make a normal change without needing to panic, the handover is not finished, regardless of what the project plan says.
This is also where tech consultancy should differ from cheerleading. A firm worth hiring has to be willing to say "your team is not ready to own this yet" and mean it, and then produce a plan to get them there - rather than quietly extending the dependency forever.
How this list actually answers the DIY pushback
When a client says "we could build that ourselves," the right reply is not "no, you could not." Often, they could.
The useful reply is "compare what you would produce against this list."
If the same artefacts can be produced internally, with the same rigour, then building internally is usually the right call. The business will learn faster, own the result cleanly, and keep the optionality to improve it later.
If the list cannot be produced - because nobody has the time, nobody has the authority, or the organisation cannot agree on what "correct" even means - then building internally is not actually cheap. It is concentrated risk with an invoice that arrives late.
Close
We are not precious about whose hands are on the keyboard.
We are precious about whether the business can still live with the result in week thirty, when the people who were excited in week one have moved on to something else.
That is what a serious engagement is built to protect. The code, at that point, is almost the easy bit.
