A small team should buy an off-the-shelf AI tool whenever its workflow looks like everyone else’s, and build only where the work depends on something no vendor has: your own rate card, your past jobs, or the gap between two tools that were never meant to talk to each other. The deciding cost is not the build, it is the upkeep. The model underneath a custom tool belongs to someone else and changes on their schedule: on 14 October 2026 OpenAI gave developers three months’ notice that GPT-4o and GPT-4.1 snapshots, fine-tuned versions included, would be removed from its API on 14 January 2027. When you buy, the vendor absorbs changes like that. When you build, you do, so only build if someone on your team is named as the owner.
The usual way a small team makes this call is a comparison on day one. The subscription costs this much a seat and does eighty per cent of what we want. A custom tool costs more up front and does all of it. Spread the build over three years and it looks cheaper.
That arithmetic assumes the custom tool, once built, stays built. Ordinary software roughly does. A tool built on a language model does not, and the reason has nothing to do with how well it was made.
The model is the small part of the system
In 2015 a group of Google engineers published a paper at NIPS, one of the leading machine learning conferences, called “Hidden Technical Debt in Machine Learning Systems” (Sculley and colleagues). Their central point was that the quick wins of machine learning are not free: real systems run up large ongoing maintenance costs. They estimated that a mature system might end up being at most 5% machine learning code and at least 95% “glue code”, the plumbing that gets data in and out of the model. They also wrote that the external world is rarely stable, and that this background rate of change is itself a maintenance cost.
That paper predates language models and describes systems at Google’s scale, not yours. But the shape carries over, and for a small team it gets worse rather than better. When Google built a model, it at least owned it. When you build on a language model today, you own only the glue: the part that pulls the job sheet out of your system, writes the instructions, reads the answer and puts it back somewhere useful. The model in the middle is rented.
The part you rent changes without asking
Models get withdrawn. OpenAI’s published deprecations page shows that on 14 October 2026 it notified developers that four models (GPT-4o, GPT-4o mini, GPT-4.1 and GPT-4.1 mini) would be removed from its API on 14 January 2027, and that fine-tuned versions follow the same shutdown date. The same page says preview models can go with much shorter notice, such as two weeks. None of this is unusual or badly behaved; it is how the platform works, and it says so.
Models also change while keeping their name. In a 2023 paper, Lingjiao Chen, Matei Zaharia and James Zou compared the March and June 2023 versions of GPT-3.5 and GPT-4 on the same tasks. Behaviour varied a great deal over three months: GPT-4 became worse at following user instructions, and both models made more formatting mistakes when generating code. The authors’ conclusion was that the behaviour of the “same” service can change substantially in a short time. Those are 2023 models and the specific results will not repeat, but the formatting finding is the one to notice. A person reading the output shrugs at a stray heading. The glue code that expected a clean table does not.
So a custom AI tool comes with recurring work that a spreadsheet macro never had: moving to the replacement model, checking that it still gives the answers the old one gave on your real material, and fixing the glue where it does not. That work arrives when the provider decides, not when you have a quiet week.
Buy where your work looks like everyone’s
This is the strongest argument for buying, and for most small teams it settles the question. A company selling meeting notes, inbox drafting or receipt categorisation inside accounting software has engineers whose whole job is absorbing those changes, because its revenue depends on the product still working after the next model release. Part of what the subscription buys is that upkeep, spread across thousands of customers. You will not do it more cheaply for one.
The test is whether your version of the job is genuinely different. Notes from a client call are much the same in a five-person agency as in a fifty-person one. Buy the tool, accept the twenty per cent it does not do, and spend the difference on something else.
Build where the job lives between your tools
Building earns its upkeep in a narrower set of cases: where the work depends on knowledge that exists only in your business, or where it sits in the gap between systems no vendor connects. A small surveying firm that writes every quote by reading the site notes, checking its own rate card and looking up what similar jobs actually cost last year is a fair example. No off-the-shelf product holds the rate card or last year’s jobs, and the person writing the quote is the one copying between three windows.
Even then, the question to settle first is not which model to use. It is who owns the tool after it is built: who notices when the answers drift, who reads the deprecation email, who reruns the checks on real quotes when the model underneath is replaced. If nobody on the team can be named, the build will work well for a few months and then quietly stop being trusted, which is worse than never having had it. Naming that person, and writing down what they will need to watch, is part of deciding whether to build at all.
Hiring someone for it
The other answer founders reach for is a hire: bring in someone technical and let them build whatever is needed. That makes sense when there is a stream of work, several systems to build and a product of your own that depends on them. It makes less sense for one tool. The upkeep described above is real, but for a single well-built system it is occasional work, not a job, and a full-time hire brought in for one build either runs out of work or starts building things to stay busy.
The more useful hire for most small teams is not an AI engineer. It is making sure that whoever already runs your systems (the operations lead, the person who set up the CRM) understands what the tool does well enough to own it, with a written description of what to check when something changes.
What this costs a build shop to say
We build custom systems, and the argument above says most small teams should not commission one. That is deliberate. A tool bought from a vendor whose business is keeping it working will usually outlast one built for you, unless your work is genuinely unlike other people’s.
It also says something about our own offer. A good handover makes the upkeep visible and manageable; it does not make it disappear. Whoever owns a tool we build will still be the person who reads the deprecation email and reruns the checks, and if that person does not exist, the honest advice is to buy something instead.
Common questions
- Should a small business build or buy AI tools?
- Buy, unless the work depends on something no vendor has, such as your own pricing, your past jobs or a gap between two tools nobody connects. A vendor whose product is the tool absorbs the cost of model changes for all its customers at once. A custom tool puts that cost on you, so build only where the fit is worth it and someone on the team will own the tool after it is built.
- What does it cost to maintain a custom AI tool?
- The recurring cost is mostly change you do not control. Model providers retire models on their own schedule: in October 2026 OpenAI gave three months’ notice that GPT-4o and GPT-4.1 would be removed from its API in January 2027. Each change means moving to a replacement, rechecking the output on your real material and fixing the code that handles the answers.
- Do AI models change after you build on them?
- Yes. They are withdrawn and replaced, and their behaviour can shift even under the same name. A 2023 study by Chen, Zaharia and Zou found that GPT-4’s behaviour changed substantially between March and June 2023, including a drop in following instructions and more formatting mistakes in generated code, which is the kind of change that breaks a custom tool.
- Should I hire an AI engineer for my small business?
- Usually not for a single tool. A hire makes sense when there is a steady stream of systems to build. For one well-built system the upkeep is occasional work, and it is usually better owned by someone who already runs your operations, with a written note of what to check when the model underneath changes.