Build, buy or wait: how to decide for each AI workflow.

“Should we build our own AI or buy it?” sounds like one decision. In practice it is a dozen, one for each workflow, and the answers differ. A company that answers once, as a policy, ends up forcing a product onto the workflow where it competes, or building its own meeting summaries.

Decide per workflow instead. Buy what every company needs. Build where the workflow is how you compete, or where you must control the data, the prompts and the evaluation. Wait when nobody owns the workflow or its data can’t be reached. When it’s close, test both options on the same examples.

Why is build versus buy the wrong first question?

Because it skips the questions that decide it: which workflow, who owns it, what it costs today and what a good result looks like. Without those, a product demo and a custom proposal can’t be compared, because neither has been measured against anything. It also leaves out the third answer, waiting, which is cheaper than a stalled project. The short answer in the questions leadership teams ask before a first project still holds; this is the long version.

Run each candidate workflow through the table. The column that collects most answers is a starting position, not a verdict.

The default, when nothing points strongly elsewhere: buy for common work, and build only what products fail to do on your own examples.

The same company should usually buy, build and wait at once, for different workflows.

When is buying the better answer?

When the job is the same in your company as everywhere else: summarizing meetings, drafting and rewriting, searching documents a person can already open, transcribing calls. Vendors spread the cost of these features across many customers and improve them faster than one company could.

Buying works best when three things are true. The product reaches your systems through standard connectors. Its data terms and processing locations pass your data protection officer’s review. And its idea of a good answer is close enough to yours that configuration, not code, closes the gap.

The costs are visible: prices that grow with adoption, the vendor’s roadmap instead of yours, and quality you can only measure from outside. For general work, they are usually worth paying. Productivity assistants and custom systems do different jobs, and you will probably need both.

When is building the better answer?

Build where the workflow is how you compete: your service promise, your quoting, your way of handling claims. Products serve the average customer, and your differentiator is, by definition, not average.

Build also when you must control what defines quality: data that has to stay in your cloud or on your servers, prompts that encode policy you can’t hand to a vendor, an evaluation set and audit trail you must own because decisions will be questioned later. And build when a product almost fits but can’t reach your systems or follow your rules, the gap custom AI software exists to close.

Building doesn’t mean starting from nothing. You still buy model access, cloud and often search components; what you build is the workflow-specific layer on top. You also take on its upkeep: monitoring, regression checks when a provider updates a model, and an owner after launch.

When is waiting the right call?

Wait when the conditions for any answer are missing:

• No owner. Nobody will define good answers, approve the design or run the system after launch.
• No reachable data. The information lives in personal folders, email threads or people’s heads.
• A moving process. The workflow is being redesigned or its core system replaced, so anything built now gets built twice.
• High risk, unclear benefit. Errors would be expensive and nobody knows what the current process costs.

Waiting is not doing nothing. The first project becomes naming the owner, opening data access or measuring the baseline, and the workflow returns to the table when that is done.

What does a hybrid look like in practice?

The usual result is a stack rather than one answer: buy the platforms and general assistants everyone uses, then build the workflow-specific parts on top, such as retrieval over your sources, your rules, review screens, integrations and the evaluation set.

Take an illustrative comparison in a retailer’s service team. Its helpdesk product offers an AI feature that summarizes tickets and suggests replies from the knowledge base. The returns team wants something else: each return decision prepared with the order, the photos and the policy paragraph that applies, for a person to confirm.

Run on the same few hundred past returns, the answers split. The bought feature writes a good summary and a polite reply, and is live in days, but it can’t read the order system, check photos against the product record or cite the policy, so it can’t prepare the decision. A custom workflow, like the illustrative returns engagement, can, after a pilot of about six to ten weeks. So: keep buying the reply feature, build the decision step, and wait on automating refunds until that step has a measured record.

How do you compare a product and a custom build fairly?

Use the same evidence for both. Shortlist two or three products, build a custom prototype in roughly the same time, and write the acceptance criteria before anyone runs anything.

1. One evaluation set. A few hundred real cases with expert-approved answers, awkward ones included, run on your data under a proper data agreement rather than on demo examples.
2. Results by case type. An average hides the cases each option fails.
3. Review time. The minutes a person spends checking and correcting each output. It is often the largest cost, and the one demos hide.
4. Cost per finished task. Licenses or usage, infrastructure, review time and upkeep, at your real volume.
5. Integration. Whether it reads and writes the systems the workflow needs, with the permissions your people already have.
6. Outcomes, not polish. A prototype looks rougher than a product; compare what each gets right.

What should you ask about lock-in and exit?

Every option locks you in somewhere, so ask before signing, not when leaving:

• Can we export prompts, configuration, evaluation sets and logs in a usable format?
• Who owns the prompts and evaluation sets we create inside the product? Ask counsel as well as the vendor.
• What happens when the vendor changes the model underneath: do we get notice, and can we re-test on our evaluation set before it reaches users?
• Can we bring our own model provider, and where is our data processed?
• For a custom build: do we own the code, prompts, evaluation sets and documentation, and is the design model-agnostic?

The full questionnaire belongs in vendor due diligence. Either way, your evaluation set is the best insurance: with it, switching becomes a test rather than a leap.

One table, every workflow

List your candidate workflows, run each through the table and mark buy, build or wait. For the close calls, run the side-by-side test before anyone signs. An AI strategy and discovery engagement ends with exactly this call for each candidate: build, buy, wait or stop. Or describe one workflow and start there.