Should we build our own AI tools in-house?
Quick answer: Build AI tools in-house only when the workflow is genuinely proprietary, your data cannot leave your systems, or the capability is the reason customers choose you — and only once you have named the person who will maintain it after launch. The deciding cost is not the build. An in-house tool built on third-party model APIs typically needs 15 to 25% of its build cost in engineering attention every year just to keep working as models are deprecated and integrations drift, which on a £15,000 to £60,000 build is £2,250 to £15,000 a year before a single new feature is added. If an off-the-shelf product does 80% of the job for a subscription you can afford, buy the product.
| Option | Typical cost | Best used for |
|---|---|---|
| Use an off-the-shelf AI product | £20 – £60 per user/month | Drafting, summarising, research, coding help. Commodity work your competitors do identically. |
| Train the team on existing tools | £1,000 – £5,000 one-off | The answer far more often than anyone selling you a build will admit. |
| Build a proof of concept | From £8,000 | Testing whether your specific idea survives contact with your actual data. |
| Build a production in-house tool | £15,000 – £60,000 | Your own data, unattended running, or decisions that cost money when wrong. |
| Keeping it alive, per year | 15 – 25% of build | Model deprecations, integration drift, and the engineer time to handle both. |
Per-user pricing reflects typical UK business-tier AI product subscriptions. Build costs reflect senior freelance pricing with no agency overhead.
The question that actually decides it
Most build-versus-buy advice tells you to weigh control against speed, or customisation against cost. That framing is not wrong, but it is not what determines the outcome eighteen months later.
The question that decides it is simpler: who is the second person? If the individual who builds this is unavailable for a month, who keeps it running? If the honest answer is “nobody”, you have not built a tool. You have built a dependency on one person's availability, and you will discover that on the worst possible day.
Every other consideration — cost, control, speed — is recoverable. That one is not.
Why the economics inverted
Building software used to be the expensive part and maintenance the tail. AI collapsed the build cost and did not touch the maintenance cost, so the ratio flipped.
A tool that once cost £30,000 to build and £6,000 a year to maintain might now cost a fraction of that to build — and still cost something meaningful every year to keep alive. The maintenance is no longer a percentage of the build. In many cases it exceeds it within three years.
This is the single most common miscalculation I see. Businesses compare a one-off build price against an annual subscription and conclude that building wins. That comparison is wrong on both sides: the build is not one-off, and the subscription includes a team keeping the thing working.
The honest three-year comparison
Do this arithmetic before you decide. Take the subscription you would otherwise pay — per seat, times seats, times 36 months. Then take the build cost, add three years of maintenance at 15–25%, and add the internal time your own team will spend owning it.
For a ten-person team on a £40 per-user product, three years is roughly £14,400. Against a £15,000 build plus around £7,000 of maintenance, building is close to break-even — and you carry all the risk. At forty users the same product costs about £57,600 over three years, and building becomes clearly cheaper.
Seat count is usually the variable that decides it, not features. Per-seat pricing scales with your headcount; a custom build does not. That is the real reason growing companies eventually build.
When you should not build, and nobody will tell you
If your team wants to draft faster, summarise documents or research more efficiently, they need training, not software. A few hours teaching people to use tools they already have will beat any custom build and cost a fraction as much.
If the process only happens a few times a month, automation will not repay its own maintenance. If nobody can write the rules down beforehand, you will not get an automated process — you will get a system that is confidently wrong in ways nobody notices.
I say all of this to people who arrive wanting to build, and it costs me work. It is still the right advice.
If you do build, build it to survive you
The deliverable is not working software. It is working software your own team can keep working. That means documentation explaining why, not just what. Tests on the parts where a silent error costs money. A runbook in plain English. Code in your accounts, not the builder's. And a named owner inside the business with the time to be one.
I build this way because I have watched the alternative. I grew an app agency from myself to 100 staff and sold it in 2015 — the whole exercise was making a business that ran without me. The same principle applies to a single internal tool.
Related reading: Who maintains the AI tool your team just built?
Common questions
Should we build our own AI tools in-house?
Build in-house only when the workflow is genuinely proprietary, your data cannot leave your systems, or an off-the-shelf product would cost more over three years than owning it outright. If a commercial product does 80% of the job for a subscription you can afford, buy the product — the subscription you resent is almost always cheaper than the maintenance you cannot escape.
How much does it cost to build an AI tool in-house in the UK?
A proof of concept starts from £8,000. A production tool built on your own data typically runs £15,000 to £60,000. Budget 15–25% of the build cost per year to keep it working as models are deprecated and APIs change.
What is the real risk of building AI tools in-house?
Not that it fails on day one — it usually works. The risk is that the person who built it moves on, an upstream API changes, or it quietly produces wrong output that nobody catches for months. All three are ownership problems, not AI problems.
Can our team build it themselves with AI coding tools?
Often yes, and increasingly they already have. Modern coding tools let a capable non-developer produce something that genuinely runs. The gap is not building it — it is testing, error handling, security, and knowing what breaks silently. Get help reviewing what your team built rather than paying someone to rebuild it.
What data protection issues apply to in-house AI in the UK?
Under UK GDPR you remain the data controller regardless of which model you use. The practical questions are where data is processed, whether it is used for training, and whether you can evidence both. Self-hosting removes the transfer question but adds infrastructure cost and responsibility — it is a trade, not a free win.