The tool everyone agreed was a good idea
Most contracting, M&E and FM businesses have one of these somewhere. A spreadsheet an estimator built that prices a package in an afternoon. A proof of concept a consultancy demoed last spring that impressed the whole room. A licence the business is still paying for. They work. None of them is how the job gets done on a Tuesday morning.
No survey is quoted below, and be wary of the ones that are - the failure rates that circulate about internal AI projects are usually somebody's sales material. What follows is four mechanisms instead. Each is structural, each is visible before a penny is spent, and none is about whether the technology works.
One - it never clears the prioritisation queue
An internal tool competes for the same people and money as work carrying a client name and a contract number. That is not a fair fight and it is not meant to be. The bid due Thursday has a deadline that punishes slipping; the tool has a deadline somebody invented at a management meeting. When the week tightens, the invented deadline moves, then moves again. Nothing is ever cancelled. The tool simply spends eighteen months as next quarter's priority.
The sharper version: whoever understands a process well enough to specify a tool for it is usually the person best at doing it by hand - the estimator who knows which rates still hold, the QS who knows what the contract says rather than what everyone assumes. That person is, by definition, the busiest in the business.
Two - the pilot dies in procurement
Buying rather than building relocates the problem. Operations watch the demo; the questions that follow come from legal, IT, insurance and, where the data belongs to a client, that client's governance team. Few are difficult. What kills the pilot is that each needs a different senior person, and none of them has the pilot in their objectives - so nothing is refused, it waits. A pilot that pauses for six weeks does not resume, it restarts: the champion is back on a job, the trial access has lapsed, and the demo has to be sold a second time.
The questions themselves are short, and every one is answerable:
- The security questionnaire - which arrives weeks after the enthusiasm did, and lands on whoever answers questionnaires rather than whoever wanted the tool.
- The data protection assessment, which needs somebody to decide what personal data actually sits in a job file. In most businesses nobody has written that down.
- Where the data sits, who processes it, and whether it trains anything. Real answers exist, but they have to be in writing before anyone signs.
- The professional indemnity position - your insurer's view of AI-assisted work going out under your name is a fact to obtain, not an opinion to form internally.
- Contract flow-downs. On plenty of jobs the project data is not yours to move, and the contract has something to say about subprocessors and notice.
Three - the demo is not the job
A working demo is genuinely persuasive, which is why this one gets underestimated. But a demo runs on a clean input: one tidy specification, one well-formed schedule, a scope written in complete sentences by somebody who wanted it understood. Real work arrives as a scan of a marked-up drawing, a specification that contradicts the drawings, an addendum issued the day after the take-off was finished, and a client template that has to be used because the client says so.
The demo shows the middle of the process. The job is almost entirely edges:
- Intake - can it take the input in the state the input is genuinely in, including the bad scan and the twelfth revision?
- House format - does the output land in your template, with your numbering, ready to issue? A good draft in the wrong format is a re-typing job.
- Checkability - can a reviewer verify it against the source in minutes? If checking means redoing the work, nothing was saved.
- The signature - a competent person puts their name to it, and will want to see where each figure came from. Traceability is a delivery requirement, not a feature.
Four - it decays the moment its author moves on
Tools built in the gaps between real work have no owner, no version and no review date. Rates move, standards are revised, the client changes their template, and the person who built it leaves or is promoted into a job with no room to maintain it. No budget carries a maintenance line for something built in slack time.
Then it is wrong once, in front of a client, and that is the end of it. Trust in an internal tool is asymmetric - it accumulates slowly and is spent in a single meeting. This is the mechanism behind the tools that did ship and are quietly no longer used, which is the category businesses forget to count.
What the ones that survive have in common
- They are attached to a deliverable, not a capability. Nobody funds 'AI for estimating'. People fund the tender that has to go out on the 14th.
- Somebody is named - not a steering group, one person whose week is measurably worse if it does not land.
- They are pointed at the ugly input in the first week, before anyone has been impressed by anything.
- They produce something usable on the day it arrives: your template, your numbering, your format.
- They can be stopped. Something stoppable on short notice clears approval faster, and being wrong costs a month instead of a contract term.
- The audit trail comes with the deliverable rather than after it. A reviewer who cannot trace an output back to its source will not sign, and an unsigned draft has produced nothing.
When building anything is the wrong answer
An argument like this is worth little if it ends with 'so commission something'. Several situations call for doing nothing, buying the standard product, or hiring instead.
- The process is genuinely standard. If your variation workflow is the same as everybody else's, a packaged product gets you there sooner and cheaper.
- The process is about to change. Automating a workflow six weeks before it is redesigned buys an expensive fossil.
- Nobody agrees what good output looks like. If two directors would mark the same document differently, no tool settles that - it industrialises the disagreement.
- There is nobody to sign. If no competent person has capacity to review, faster drafting unblocks nothing; it moves the queue one step downstream.
- You can hire. A senior person compounds - they absorb the work nobody scoped and train whoever comes next. External delivery is for the peak a role cannot absorb, not a substitute for it.
- You cannot check the work. Output taken on trust is worse than none, because it goes out carrying your name and your exposure, not the supplier's.
What this looks like in BuiltAI
Built to Order answers a narrower question than 'should we build an AI tool'. It answers what to do about the deliverable that cannot slip when your own bench is full: the pack methodology runs against your brief, a named senior reviewer validates before anything reaches you, and your competent persons review, approve and issue - with the audit trail produced alongside the deliverable rather than reconstructed afterwards.
It is shaped against the four mechanisms. Commissioned per deliverable rather than as a capability programme, so it never has to win the prioritisation argument against a bid. Engagement by engagement on thirty days' notice, so a stall costs a month, not a contract term. Output in your house style, on your masthead, usable on arrival. Your inputs stay yours and are never used to train any model.
One caveat, in the spirit of the section above: engagements are quoted against a brief, and the brief is where the honest answer is sometimes that you should not commission this at all. That conversation is cheaper before the work than after it. And no client results are published here yet - when there are, they will be published named, or not at all.