Build versus buy for AI features
How to decide whether an AI capability should be bought, switched on in software you already use, or built for your business.
The short answer
An AI capability can reach a business by three routes. You can buy a product that does the task, subscribe and use it. You can switch on the AI feature that has appeared inside software you already use, your CRM, your accounting tool, your support desk. Or you can build the capability for your business: a rented model connected to your own data, rules and workflow. The rule of thumb is to buy when the need is common and the product is mature, to switch on when the existing software does it adequately under acceptable terms, and to build when the capability is specific to how your business works or touches data you must control. Building has become far cheaper than it was, because nobody trains a model any more; what you build is the integration with your data and your process, and that is where the value was all along. The decision is not permanent. Products catch up, features appear in software you already pay for, and anything you built must keep earning its maintenance, so the question is revisited yearly.
The three routes
| Route | Best for | Advantages | Costs and risks |
|---|---|---|---|
| Buy a product | Common tasks: transcription, translation drafts, writing help, meeting notes, generic OCR | Mature, improving, cheap, no maintenance | Generic; another vendor; check data terms; may not fit the workflow |
| Switch on a feature in existing software | Tasks within that software’s domain | No new vendor; data already there; fast | Quality varies; vendor data terms; deepens dependency; limited to the vendor’s imagination |
| Build on your data and rules | Capabilities specific to your process, categories, tone, data | Fits exactly; grounded in your data; you control data flows; model swappable | A project; needs maintenance; needs ownership |
Deciding for a given need
- Describe the task precisely, including the data it needs and the workflow it lives in.
- Ask whether it is common or specific: would a competitor’s version be the same?
- Check the software you already pay for for a feature, and read its data terms.
- Trial the product or feature on real examples for a week; measure quality and fit.
- If it fits, buy or switch on, under business terms, and move on.
- If it does not, scope the build: data sources, rules, workflow, model, evaluation, owner.
- Cost both over three years, including maintenance and the time of the people using them.
- Decide, document why, and set a date to revisit.
How the answer changes
What needed building two years ago is often a product now. Features that were checkboxes are becoming capable. Models are cheaper and better, so the built option is more powerful for the same effort. The businesses that do well treat the map as moving: they buy the commodity, build the specific, keep what they build swappable and small, and look again every year at whether a product has caught up or a feature has appeared.
What this means for you
Buy AI for common tasks from mature products, switch on features in software you already use when they do the job under acceptable terms, and build when the capability is specific to your data, rules and workflow, which is where the real value sits. Trial before deciding, cost over three years, keep what you build small and swappable, and revisit yearly as the map moves.
Frequently asked questions
Why build anything when there is a product for everything?
Because the product does the common version of the task, and the value in your business is in the specific version: your categories, your rules, your data, your workflow, your tone. A generic AI email assistant drafts generic replies; one grounded in your policies and order data drafts yours. Building no longer means training a model; it means connecting a rented model to your own data and rules, which is a small project with a large difference in usefulness.
When is buying clearly right?
When the need is common and well served: transcription, translation drafts, general writing assistance, meeting notes, image generation, standard OCR. Mature products do these better and cheaper than anything built, they improve without your effort, and the data involved is usually not your most sensitive. Buy, under business terms, and spend the building effort where you are different.
What about the AI features appearing in our existing software?
Often the best first option: no new vendor, data already in the system, terms already agreed. Check three things: whether the feature actually does what you need well enough, what the vendor's terms say about using your data for their models, and whether it deepens a dependency you were already worried about. If it passes, switch it on and measure. If it is a checkbox feature that does the task poorly, the built option remains.