Choosing between buying an AI tool and building one: a two-hour comparison with five questions

Every team that wants an AI tool meets the same fork: buy something that exists, or build something that fits. Long debates rarely help, because the two options are usually compared on different things: a price for one, a feeling for the other. A short, structured comparison does better. Set aside two hours with the person who owns the task and the person who pays, and answer five questions for both options.

Question 1: what exact job must the tool do?

Write the job in one sentence with a measurable result: "draft first replies to supplier emails, so that a person only edits and sends" or "summarise service call notes into the format of our ticket system". If you cannot write the sentence, you are not ready to choose either way.

Then list three to five real examples of the job from last month. Both options must be tested on the same examples. A bought tool that handles the generic case well but fails on your two awkward ones is a common outcome, and you want to find it before the contract.

If an off-the-shelf tool does the job on your examples with only settings changed, the comparison is almost over. Building is justified when the job depends on your own rules, data or systems in a way no product covers.

Question 2: who owns the data, and where does it go?

For a bought tool, ask the vendor in writing: where is our data stored, is it used to train models, who at the vendor can see it, how long is it kept and can we delete it on request. Read the answers against the data you will actually send. Customer names, prices and contracts need a firmer answer than public product descriptions.

For a built tool, the data still goes somewhere, usually to a model provider's interface. The question is the same, and you are the one who has to check the provider's terms and keep the setup secure. Building does not make the data question disappear; it moves the work to you.

Write one line per option: "data stays in X, is not used for training, can be deleted by Y". An unclear line is a finding.

Question 3: what does it cost per year?

Compare the first-year cost and the yearly cost afterwards, because they differ. Use the same lines for both options:

• Licences or usage charges. For usage pricing, estimate from your examples: how many requests a month, at what size. A monthly cost estimate before you build shows the method.
• Setup. Configuration and training for a bought tool; design, development and testing for a built one.
• Staff time. Checking outputs, fixing mistakes, answering user questions. This is often the largest line and the one most often left out.
• Maintenance. Vendors change prices and features. A built tool needs someone to keep it working when the model or an integration changes.

Use rough figures and ranges, and agree an hourly rate for staff time with finance. The point is not precision. It is to see whether the options differ by ten per cent or by a factor of three.

Question 4: how do we get out?

Almost nobody asks this before starting, and everyone wants the answer later. For a bought tool: can we export our data and settings in a usable format, what is the notice period, and what would we lose on the day we leave? For a built tool: who understands how it works, is it documented, and what happens if the person who built it leaves?

A simple test: describe what you would do on the day the tool stops working. If the answer is "go back to the manual process", check that the manual process still exists and that someone still knows how to do it. If the answer is "nothing, we would be stuck", the dependency is larger than the benefit looks.

Question 5: when do we review, and who decides?

Pick a date six months out and a named person who decides to continue, change or stop. Write down in advance what result would justify continuing, for example "at least 70 per cent of drafts used with small edits, and total cost not above the manual process". Without this, tools stay in place by inertia. A weekly one-page report gives you the facts for that review.

Reviewing also means you can choose the cheaper, reversible option first. A bought tool on a monthly plan is easier to leave than a custom build, so starting there and building later, once you know what the job really needs, is often the sound order.

How to run the two hours

1. First 20 minutes: write the job and collect the examples (question 1).
2. Next 30 minutes: one person contacts the vendor or checks the documentation for the data answers; another drafts the build outline (question 2).
3. Next 40 minutes: fill in the cost lines for both options (question 3).
4. Next 20 minutes: exit for both options (question 4).
5. Last 10 minutes: set the review date and the decider, and record the decision and the reason (question 5).

Keep the result on one page: two columns, five rows. If you want a broader checklist for larger platforms, the buy-versus-build checklist for enterprise AI agents goes further.

Common mistakes

• Comparing a demo with an idea. The bought tool looks finished and the build looks flexible. Test both on the same real examples.
• Leaving out staff time. Both options look cheaper than they are.
• Treating the data question as the vendor's problem. You decide what you send.
• No exit plan. The cost of leaving appears only when you want to leave.
• No review date. The first decision becomes permanent.

Summary

Buy or build is easier to decide when both options answer the same five questions: the exact job, data ownership, cost per year including staff time, the way out and a review date with a named decider. Two focused hours usually give a clear answer, or show exactly which fact is missing.

Sources

• Common practice for small and mid-sized teams, offered as a practical guide. No client results or market figures are claimed in this article. Adjust the questions, the cost lines and the review period to your own situation.