Key takeaways
- Building an AI feature has never been easier, which is exactly why the decision needs more discipline, not less.
- The build is the cheap part. Owning it for three years is the expensive part.
- Build only when the capability differentiates you, nothing suitable exists, and someone will still own it in two years.
- Configure and buy first. It teaches you what you actually need, at a fraction of the commitment.
A capable person with modern tools can now assemble a working AI feature in a weekend. This is genuinely remarkable, and it has quietly made the build versus buy decision harder rather than easier, because the cost that used to prevent bad building decisions has largely disappeared while the cost of living with them has not.
The four questions
Work through these in order. A no at any point is a strong signal to buy and configure instead.
1. Is this a differentiator or a utility?
Does the capability affect why customers choose you, or is it internal machinery? A logistics firm's routing intelligence may be genuinely differentiating. Its expense processing is not, however tedious it is.
Utilities should be bought. There is no strategic value in owning a slightly customised version of something every business needs, and it competes for the same attention as the things that do differentiate you.
2. Does something suitable already exist?
Search properly before concluding it does not. This category produces new products weekly, and many industry-specific tools now exist for problems that had no vendor eighteen months ago.
Watch for the most common failure here: a product exists that covers ninety per cent of your requirement, and the remaining ten per cent is used to justify a build. Ask whether that ten per cent is genuinely necessary or is simply how you happen to do things now.
3. Who owns it in two years?
The question that most build decisions never survive honestly. Name the person. If the answer is the enthusiastic operations manager who built it in their own time, you are creating an operational dependency on one individual's continued employment and continued interest.
Custom AI components need real maintenance. Models are deprecated, interfaces change, prompts that worked degrade when the underlying model updates, edge cases surface. This is not exotic work but it is continuous, and it needs an owner with time allocated rather than goodwill.
4. What happens when it is wrong?
A commercial product comes with a vendor, a support channel, a track record and, usually, contractual accountability. Something you built comes with you. If the output feeds a decision with financial, legal or safety consequences, that difference is worth a great deal.
The question that ends most debates: if the person who builds this leaves in eight months, what happens? If the honest answer is that it quietly stops being maintained and eventually stops working, you have not made a build decision, you have made a dependency.
The cost comparison people get wrong
| Cost | Buy and configure | Build custom |
|---|---|---|
| Time to something usable | Days to weeks | Weeks to months |
| Upfront cost | Licences plus a one-off setup fee | Development time, often underestimated by half |
| Ongoing cost | Predictable subscription | Usage, hosting, and continuous maintenance attention |
| Who fixes a fault | The vendor, under a support agreement | You, at whatever hour it breaks |
| Model upgrades | Arrive automatically | A project each time, with retesting |
| Security and compliance | Vendor certifications you can point to | Your responsibility to establish and evidence |
| Cost of abandoning it | Cancel at renewal | Sunk cost plus a migration |
The row that decides most cases is model upgrades. Bought software absorbs the improvement automatically; you wake up to a better product. A custom build has to be revisited, retested and sometimes rewritten every time the underlying model changes materially, which in this category is often.
The middle path most businesses actually want
Build versus buy is a false binary. Between them sits configuration, which is where the majority of real value has been sitting for the last few years and where the return on effort is highest.
Configuration means taking a commercial product and shaping it to your organisation: connecting it to the document stores that make it useful, creating reusable task templates for the work your teams repeat, mapping models to jobs, setting the guardrails, and writing the guidance that tells people what to do with it.
This is a fraction of the effort of building, produces most of the benefit, and leaves you free to switch providers later because you have not entangled your processes with one vendor's internals. It is also, notably, unglamorous, which is why it is frequently skipped in favour of something more interesting and less useful.
When building genuinely is right
Four situations where the answer flips:
- The capability is the product. If what you sell is improved by the AI component, owning it is strategic rather than incidental.
- Your data is the advantage. If the value comes from proprietary data nobody else holds, no vendor can package it for you.
- Constraints rule out vendors entirely. Sovereignty, isolation or regulatory requirements that no commercial product meets.
- Volume changes the economics. At sufficient scale, running your own version of a narrow capability can be materially cheaper. This threshold is higher than most people assume, so check the arithmetic before relying on it.
Even in these cases, the sequencing usually holds: buy something adequate now to learn what you actually need, then build the specific piece that matters once your requirements are grounded in experience rather than speculation.
A pattern that works well: configure a commercial assistant for the whole organisation, and reserve custom development for the one or two workflows that are genuinely specific to your business. Broad capability bought, narrow advantage built.
Frequently asked questions
Should we build our own AI tool or buy one?
Buy and configure first, unless the capability differentiates you, nothing suitable exists, and you can name the person who will still own it in two years.
How much does building cost?
The build is the smaller half. Budget for maintenance as models and interfaces change, monitoring, security review, and keeping at least two people capable of working on it. The second year is where the real number appears.
What is a good first AI project?
A properly configured commercial assistant with admin controls, spending limits and task-specific guidance. Fast, reversible, and it teaches you what you genuinely need before you commit to building.
Our team already built something. Should we scrap it?
Not automatically. Ask whether it is documented, whether a second person could maintain it, whether it runs on organisational rather than personal credentials, and whether it has a spending limit. If not, fix those four things before deciding anything else.
Find out which one you actually need
The Clarity Package gives you an honest read on where AI helps and where it does not, including whether your requirement is a configuration job or genuinely needs building. A written summary you can take to your board, at a fixed price.