Custom AI tool, or off the shelf
Three questions that settle the decision, an honest two-year cost comparison, and the reason buying wins more often than a studio will tell you.
We build custom artificial intelligence tools for a living, so treat what follows accordingly. Most brands asking us this question should buy something instead, and the ones who should build usually already know why.
The decision is usually made emotionally and then justified with a spreadsheet. Building feels like ownership and buying feels like renting, so people build. Two years later the person who understood it has left and the tool is a liability nobody will touch.
Is this the thing you actually compete on?
First question, and it disqualifies most projects on its own. Is the process you want to automate part of why customers choose you, or is it administration that happens to be annoying?
Invoicing is not your edge. Neither is scheduling, email, bookkeeping or customer support ticketing. Those are solved, at scale, by companies whose entire business is solving them, and your version will be worse. Building there buys you a slightly better fit and a permanent maintenance obligation.
The auction work we do clears this bar precisely because the process is the business. The value is not that photographs become listings — it is that they become listings informed by 32,000 of that client’s own past items, including what each one actually sold for. No product on the market has that history, and a competitor could licence identical software tomorrow without getting any closer.
Does anything on the market fit without bending?
Second question, and it requires actually looking rather than assuming. Spend a fortnight properly trialling the two or three closest products, with your real data, doing your real task. Not the demo. Your data.
The honest bar is eighty per cent. If a product does eighty per cent of the job, buy it and adapt to the missing fifth. The instinct to reject software over a missing feature is almost always wrong, because the missing feature costs less to work around than the whole build costs to maintain.
Reject a product when it forces you to change something you cannot change — a legal requirement, a way your suppliers work, or a step your customers see. That is a genuine reason to build. Disliking the interface is not.
Who owns it in two years?
Third question, and the one that kills more custom tools than any technical problem. Name the person. Not a company, not “the studio”, a person who will still be reachable when it breaks in eighteen months.
If the answer is that the agency who built it will maintain it, that is a valid answer, and it is a recurring cost you should write into the comparison rather than discovering later. If the answer is that nobody has thought about it, you have your decision. Buy.
What is the real two-year cost?
Compare like with like, over twenty-four months, with every line that will actually be invoiced or salaried. The pattern below is what the comparison looks like once the invisible costs are written down.
| Cost line | Buying | Building |
|---|---|---|
| Up front | Setup and data migration, usually modest | The build, in full, before any value arrives |
| Monthly | Per-seat or per-usage fee, rising at renewal | Hosting and model usage, rising with volume |
| Your people’s time | Configuration and training | Specification, review, testing, then support forever |
| When it breaks | Their problem, with an agreement behind it | Yours, at whatever a developer costs that week |
| When the market moves | Included, usually, whether you wanted it or not | A project, every time |
| When you outgrow it | You migrate, painfully | You extend it, if anyone still understands it |
A rough planning figure that has held up for us: over two years, a custom tool costs about twice its build price once maintenance, hosting, model usage and internal time are counted. If a build only wins on a two-year comparison at its build price alone, it loses.
The other side of that comparison deserves the same scepticism. Buying is only cheap if you actually use what you buy. Vertice’s research on software wastage finds roughly 15% of purchased applications showing zero activity at all, with a majority used at under half their purchased capacity, and Productiv’s analysis of nearly 100 million licences over three years found around 40% of licences unused. Subscriptions are not free just because they are small — they are the easiest cost in a business to stop noticing.
What does the lock-in trade look like?
Both options lock you in. People only count one of them.
Buying locks you into a company: their pricing at renewal, their choices about what to build, their decision to be acquired or to shut down. The defence is boring and effective — check you can export your own data, in a usable format, before you sign anything.
Building locks you into knowledge. The tool depends on people understanding it, and that understanding leaves the building when they do. It also locks you into whichever model provider you built against, whose pricing and deprecation schedule are no more within your control than a vendor’s renewal notice. Writing things down is the entire defence, and it is why we build against a knowledge base rather than a pile of prompts.
Where do hybrids actually work?
The best outcome in this decision is usually not either column. It is buying the boring nine-tenths and building the narrow piece that is genuinely yours.
- Keep the bought platform as the system of record — the store, the inbox, the accounting, the place your data lives.
- Build one small thing that reads from it, does the judgement your business is actually good at, and writes the result back.
- Keep that thing narrow enough that one person can hold it in their head and a replacement could read it in a day.
- Never let the custom piece become the thing everything else depends on. It should be removable.
That pattern is what our auction client actually has. The listing platform, the bidding sites and the cross-posting are all bought and already worked. The custom build sits in the middle doing the one job nobody sells — turning photographs into 1,250 filled listing rows an auction, and it hands the finished template straight back to the platform that was always there.
What is the rule of thumb?
Buy by default. Build only when all three questions clear: the process is why customers choose you, nothing available fits without changing something you cannot change, and a named person will own it for years. Two out of three is a no.
And if you do build, build the smallest useful version, in the narrowest possible scope, and measure what it removes before adding anything. The 400+ hours we took off a client’s desk came from a tool that does one job. Not from a platform.
A studio that only ever recommends building is not giving you advice, it is quoting. Most of the time the honest answer here is buy the software, and we would rather you heard it from us before the invoice than from yourself after it.