Buy, build, or pilot: a framework for your first AI project

The first AI decision is often framed the wrong way. Teams ask, “Should we buy a tool or build our own?” But the better first question is, “How certain are we about the problem?” The answer decides whether you should buy, build, or pilot.

Buying is best when the problem is common and well understood. Building is best when the workflow is core to how you compete. Piloting is best when the value is plausible but still unproven. Confusing those three states is how companies waste money.

Do not build because you are excited. Do not buy because you are tired. Choose based on certainty, importance, and fit.

Start with the two-axis map

Draw a simple map. On one axis, put business importance: how much the workflow matters if it improves. On the other, put problem certainty: how well you understand the task, users, data, edge cases, and success metric.

High certainty and low uniqueness usually points to buying. Low certainty points to a pilot. High importance and high uniqueness may justify building, but only after you prove the shape of the solution.

• Buy: common need, mature market, low strategic difference.
• Pilot: unclear value, messy workflow, unknown adoption, or uncertain data quality.
• Build: core workflow, special data, durable advantage, and clear ownership.

When buying is the right answer

Buy when the workflow is not unique and the market has already solved most of it. Meeting notes, basic support routing, simple document search, inbox drafting, and internal knowledge search often start here. A good vendor can save months.

The buying mistake is treating a vendor demo as a workflow test. A tool can be good and still not fit your company. Before signing, test it with your real inputs, your permission rules, and your review process. Ask whether the system can explain where an answer came from. Ask how data is stored. Ask what happens when you leave.

A useful buying checklist:

• Can a non-technical team configure it without waiting on engineering?
• Does it connect to the systems where the work actually lives?
• Can it show sources, history, and user actions?
• Can you export your data and settings in a usable form?
• Does pricing still make sense if usage succeeds?

If the answer is mostly yes, buy. Do not build a commodity tool to prove you are serious about AI. Serious teams spend custom effort only where it matters.

When building is the right answer

Build when the workflow is close to the heart of the business. If your data, judgment, or process is part of your advantage, renting the entire brain of that process may be risky. This is especially true when the system will encode how your company prices, evaluates risk, matches buyers and sellers, underwrites work, or makes high-stakes recommendations.

Building does not always mean training a model from scratch. Often it means owning the workflow layer: the prompts, evaluation sets, source connections, review screens, audit trail, business rules, and measurement loop. You may still use commercial models underneath. The point is that the important logic lives where you can inspect and improve it.

For most companies, “build” should mean owning the system of work, not pretending to be a model lab.

Build only if you can answer three questions. Who will maintain it? What will make it better over time? What would be painful if a vendor changed pricing, access, or product direction? If you cannot answer those, you are not ready to own it.

When a pilot is the right answer

Pilot when the opportunity is real but the shape is unknown. This is the honest middle. You are not ready to buy because you do not know the exact workflow. You are not ready to build because you have not proven the value. A pilot is a learning machine.

A good pilot is not a mini product. It is a measured test of one workflow. It should answer: can the system reduce work, improve quality, lower risk, or create a new capability in a way the team trusts?

Keep it narrow. A hypothetical investment team should not pilot “AI for deal sourcing.” It might pilot “turn the first pass of inbound company materials into a structured memo with risks, open questions, and cited source passages.” That is testable. The broad version is not.

The decision tree

Use this plain decision tree before spending serious money:

• Is the workflow common and low-difference? Buy first.
• Is the workflow strategically important but poorly understood? Pilot first.
• Is the workflow strategically important, well understood, and hard to copy? Build or own the workflow layer.
• Is the workflow low importance and low certainty? Do nothing yet.

The last answer matters. Not every AI idea deserves a project. Some ideas deserve a better spreadsheet, a policy change, or a cleaner handoff between teams.

How to avoid the trap

The trap is committing too much before you know enough. Long procurement can hide a weak problem. Custom development can hide a missing user. A pilot can hide a lack of ownership if nobody plans what comes next.

Set a learning budget. Decide what you need to learn before the next dollar is spent. For a buy decision, learn whether the tool fits real work. For a build decision, learn whether the workflow is valuable enough to own. For a pilot, learn whether the number moves without making quality worse.

The right first AI project is rarely the biggest one. It is the one that teaches you how your organization should make the next decision.