Custom AI vs Off-the-Shelf
Both of Them Change Under You. The Difference Is Who Absorbs It.
With ordinary software the trade is familiar: off-the-shelf is the stable, cheap, boring choice and custom is the expensive one you maintain. AI inverts half of that. The product you bought is sitting on a model its vendor keeps updating, repricing and occasionally deprecating — so the stable option is not stable. It just changes on somebody else’s schedule instead of yours.
Off-the-shelf vs Custom
Their schedule · Your schedule
- Who decides when it changes
The vendor, on their roadmap, usually with an email.You, when something forces it - What happens when the model updates
Behaviour moves and you find out from users.You test, then decide whether to move - Time to something working
Days. Genuinely, and this is the real advantage.Weeks, and longer if scoped honestly - What it costs in year one
A subscription, predictable, small.A build, and it is the expensive year - What it costs in year three
More seats, more usage, a price rise you did not set.Maintenance, and only if somebody does it - How well it fits your process
Your process bends to it. Sometimes that is an improvement.It fits, including the parts that are odd - If you want to leave
Your data and configuration are in their shape.Yours, if handover was built in
The second row is the one that surprises people who have bought software before. A conventional product does not change what it does without a release note; an AI product can behave differently on Tuesday because the model underneath moved. That is not a fault, it is the category — and it means "we will just buy something" no longer means "we will just leave it alone".
Buy first, and build the part that is genuinely yours
The honest recommendation is usually to buy, and to be much more suspicious of a build than the person proposing it wants you to be. Most of what businesses want automated is not unusual, a product does it, and the product will keep doing it while somebody else pays to improve it. An agency whose only product is building will not tell you this, and it is the single most useful sentence on this page.
Build earns its place in one situation, and it is narrower than it sounds: when the thing you need does not exist as a product because it is specific to how you work. A pricing rule nobody else has. A workflow that is the business rather than a support for it. An integration with something internal that no vendor has heard of. In those cases the product does not save you money — it hides the cost inside a stack of tools that fight each other, and you pay it anyway with worse visibility.
What we would add, because almost nobody does, is that the two are not exclusive and the useful shape is usually a border. Buy for the ordinary parts, build only the genuinely unusual piece, and be strict about the line between them — because without a line the custom part quietly absorbs its neighbours a feature at a time until you have built the whole thing by accident.
And on the change problem: whichever you choose, the answer is the same and it is a test set. A few dozen real cases with the correct answers written down, run before launch and again whenever anything moves. It is the only thing that tells you a vendor update broke something before a customer does, and it is equally necessary on a product you bought.
An agency whose only product is building will not tell you to buy. That is the most useful sentence on this page.
Six questions that settle it honestly
Answer them about the specific task rather than about your business.
Does a product already do this?
Check properly, including inside subscriptions you already pay for. A surprising share of requested builds exist behind a settings page nobody has opened.
Is the unusual part actually unusual?
Frequently the brief describes something distinctive and the process turns out to be ordinary with unusual vocabulary. That is a buy.
Who maintains it in year three?
Custom has no updates arriving from anywhere. If the honest answer is nobody, buy — because unmaintained custom is the most expensive outcome available.
Must the data stay put?
If information genuinely cannot leave your environment, that narrows the field fast and can force a build. It is a real constraint rather than a preference.
How fast do you need it?
Days versus weeks is a genuine difference. A bought product running next Tuesday, replaced later if it does not fit, is a legitimate strategy.
Can you draw the border?
Buy the ordinary, build the unusual, and write down the line. Without one, the custom part absorbs its neighbours until you have built everything by accident.
What people ask about this choice
Is off-the-shelf AI not the safe option?
Safer to start, and not as stable as ordinary software. The product you bought sits on a model its vendor keeps updating, so its behaviour can move without a release note. That is the category rather than a fault — but it means buying no longer means leaving it alone, and a test set is as necessary on a bought product as on a built one.
When is custom genuinely the right answer?
When the thing you need does not exist as a product because it is specific to how you work — a pricing rule nobody else has, a workflow that is the business itself, an integration with something internal. In those cases a product does not save money; it hides the cost inside a stack of tools that fight each other.
You build things. Why would you tell us to buy?
Because the projects that go wrong are the ones where a build was chosen because a builder happened to be in the room, and those are the ones talked about publicly a year later. A smaller correct invoice is a better outcome for us than a larger wrong one.
Can we do both?
That is usually the right shape. Buy for the ordinary parts, build only the genuinely unusual piece, and be strict about the border between them. The strictness is the important half — without a line, the custom part absorbs its neighbours a feature at a time.
What happens when the vendor changes their model?
Behaviour moves, and without a test set you find out from users. A few dozen real cases with the correct answers written down, re-run whenever anything changes, is the only thing that catches it first. That applies just as much to something you bought as to something you built.
How is this different from your US page?
That page is about a market saturated with vendors and the discipline of asking whether to build at all. This is about what happens after you have chosen — specifically that both options change under you, and the only difference is whose schedule it happens on.