Anna Totterdell
Projects Director
When a buyer says "we can build that ourselves," they are usually picturing something specific and narrow - a script, a workflow, an API connector, a screen. And they are not wrong that those things are now easy to produce. If that was all a serious supplier was selling, the pushback would be entirely fair.
It is not what a serious supplier is trying to sell. The thing being bought is capability, and capability is the part that makes the narrow artefact survive real life inside the business.
What "code" actually means in a procurement conversation
Code is the thing that demos well. It is the first pull request. It is the screenshot in the deck. It is the deliverable that feels like the whole job because it is the part you can see.
It is also the part that is now easiest to produce cheaply, which is why treating it as the product is increasingly a mistake.
What "capability" actually means in a procurement conversation
Capability is the less photogenic superset around the code.
It is a scope document written tightly enough that nobody can hide inside vague language later. It is test evidence that reflects how the business actually behaves in month nine, not how a clean demo tenant behaved on day three. It is integration contracts that survive the next vendor update. It is runbooks the ops team can actually read. It is an internal owner who has been handed something they genuinely know how to run. And it is an audit trail a finance director can walk through without improvising.
Buying code without any of that gets a quick, visible win, which is often followed by a long quiet period in which "everything works" until, without warning, it does not.
The questions that expose the difference
Ask any supplier, internal or external, the same five questions before the invoice goes in, not after.
What happens when an upstream system changes without warning? What is the rollback path when a release turns out to be wrong? Who owns monitoring, and how do they find out first? What is the reconciliation rule when the two systems disagree on a value? How will correctness be proven to finance at month-end?
If the answers are hand-wavy or reliant on a single person's memory, the thing being bought is not capability. It is confidence with some code attached.
Once the workflow touches real systems, real customers, or real money movement, capability usually implies proper development and build discipline - versioning, release hygiene, change control - even if the surface-level solution looks like "just a connector between two things."
Why this gap widens as building gets easier
The first eighty percent of most automation work is now cheap and fast, which is genuinely a good thing for the market. It also means more organisations are shipping dependencies into core workflows without ever paying for what sits around the code, because nobody priced it and nobody felt any pain on day one.
This is exactly where tech consultancy earns its keep when it is done honestly. Not as a polished opinion on a slide, but as independence in the room - naming trade-offs, refusing dangerous scope, and insisting on operability standards because nobody else involved is incentivised to slow down for them.
What external help should actually look like
A supplier worth hiring should be able to point at artefacts and behaviours, not atmospheres.
There should be evidence of how the thing has been tested. There should be a visible ownership transfer, not an assumed one. There should be a change plan that fits the real business calendar - month-end, peak season, freeze windows - rather than a tidy two-week sprint universe in which none of that exists.
If a supplier cannot describe what the buyer's team will be able to do on their own after the engagement ends, what was sold was labour with a nicer label.
How this sits alongside build-versus-buy
The point is not that building is wrong, or that buying SaaS is wrong. Those decisions are context-specific and they always will be.
Whatever route is chosen, the part worth paying for is the IT and process strategy that makes the capability durable. Someone who treats handover and operability as part of the definition of done, rather than as optional work once the heroics are finished.
Close
If two quotes are wildly different in price, the question to ask is what is missing from the cheaper one. Not to catch anyone out, but because there is more than one way for a proposal to be cheap, and some of them push the cost onto the buyer later without making that visible in the pricing.
The expensive failures rarely come from paying too much for specialist involvement. They come from buying code, skipping capability, and discovering the gap the first time the workflow touches money, customers, or compliance.
Building in-house is a legitimate choice. Using AI-assisted development is a legitimate choice. Neither of them removes the need for production standards - the operation that sits on top will not pretend along with the decision.
