Build or Buy AI? How a CEO Should Decide

What is the difference between configuring, buying and building AI?

Most guides treat this as a two-way choice. For a mid-market company it is a three-way choice, and the option most often skipped is the cheapest one.

• Configure: switch on and set up the AI already inside tools you pay for, like your office suite, CRM or help desk, or set up a shared project in a general AI assistant with your own instructions and documents. Time to first use: days. Main cost: licenses, setup and training. Main risk: it only does the generic version of the job.
• Buy: pay for a focused product built for one job, such as meeting notes, invoice processing or support triage. Time to first use: weeks. Main cost: subscription plus integration. Main risk: lock-in, and paying for features nobody uses.
• Build: develop something custom on top of AI models, connected to your own systems and data. Time to first use: months, plus upkeep for as long as it runs. Main cost: people, to build it and to maintain it. Main risk: it works in the demo and decays after launch.

The default order is configure first, buy second, build last. We set it out briefly in our guide on how a CEO should prioritize AI projects. The rest of this post is about how to apply that order to a real decision, and when to break it.

What does the evidence say about buying vs building?

The market has moved hard toward buying. Menlo Ventures found that in 2024, 47% of enterprise AI solutions were built internally and 53% purchased, and by 2025, 76% of AI use cases were purchased rather than built.

Results point the same way. MIT NANDA's GenAI Divide report found that buying AI tools from specialized vendors and building partnerships succeeded about 67% of the time, while internal builds succeeded only one-third as often.

Two cautions. Both studies lean toward large enterprises, which have engineering teams most mid-market companies do not. That makes the case for buying stronger for you, not weaker. And "buying" in these studies includes real partnership and setup work. A purchased tool that nobody fits into the workflow fails just as surely as a custom one.

How do you decide whether to configure, buy or build?

Use this six-step test on one AI idea at a time. Do it in a single working session with the business owner of the workflow and someone from IT in the room, and write the answers down.

1. Write the job in one sentence, with a number. For example: "Reduce quote turnaround for inbound requests, measured weekly in the CRM." If you cannot name the number, stop. You are not ready to choose a tool.
2. Map the workflow as it runs today. List every step from trigger to finished output, who does it and which system it lives in. Mark the steps AI could draft, check or route, and the step where a person approves the result.
3. Run the configure test. Do the steps AI would handle live inside a tool you already pay for? Is the data it needs already in that tool? Could a capable person set it up in under two weeks? Three yeses: configure it, and skip the rest of the test.
4. Run the buy test. Is this a job many companies share, like meeting notes, accounts payable or first-line support? Can you find at least three vendors selling a product for exactly this job? Does at least one connect to the systems from step 2? If so, shortlist two and trial them on your real work, not the vendor's demo data.
5. Run the build test. Build only if all four are true: the workflow is part of how you win, not just how you operate; it depends on data or judgment only you have; it crosses systems no product connects; and a named person will own and maintain it after launch. If any one is missing, go back to buy or configure, or narrow the scope.
6. Pilot with a stop date. Whatever you chose, run it for 30 days inside the real workflow with the real team. Check the number from step 1 at the end. Then scale it, fix it or stop it. A pilot without a stop date is how pilot sprawl starts.

The order matters. Each test is cheaper to pass than the one after it, so you only pay for a build when the cheaper options have failed for a reason you can name.

When is building custom AI worth it?

Building makes sense when the workflow sits close to your advantage. Think of a pricing model that uses your own margin history, an estimating or underwriting step that reflects years of your team's judgment, or a quoting flow that pulls from three systems no vendor connects. A generic tool flattens exactly what makes you different.

Sometimes that is reason enough to build straight away. One insurance client of ours went straight to building for submission triage and underwriting support, because how they judge risk is the business. No off-the-shelf tool would carry that judgment, and they had a technical lead ready to own what got built.

Even then, "build" rarely means starting from scratch. Most custom AI in a mid-market company is assembly: a model you rent, your data, a few integrations and clear instructions. A sound path is to configure a rough version first, such as a shared assistant project that drafts the output for a person to review, and automate the full flow only once those drafts are reliably good.

A manufacturer we work with did exactly this with quoting, which was taking up most of its sales lead's week. Instead of building an inbox agent, the team set up an assistant project that drafts replies from their quoting checklist and real customer threads, for a salesperson to review. The first live draft was close enough to keep going. The agent can wait until the drafts have earned it.

The cost people forget is the second year. Models change, your systems change and the person who built it moves on. We saw a version of this with a 12-person manufacturer that spent a year and a half co-developing custom software. When it came time to add AI, that system was the thing in the way. They are now looking at a vendor that covers only the 70% of the features they actually use.

Before you approve a build, ask who will own it in 18 months and how much of their week it will take. If nobody can answer, you are buying a future problem.

What are the signs you chose the wrong path?

• You built what you could have configured. Your custom tool now duplicates a feature that arrived in your CRM or office suite a few months later.
• You bought a product nobody opens. A month after launch, use is limited to a handful of enthusiasts. That is usually a How problem, not a tool problem.
• You configured something that needed more. People copy and paste between the AI and two or three other systems to finish each task. That is the signal to look at buying or building.

Each of these is fixable, and they share a root: the tool was chosen before the What and the How were clear.

Who should make the build-or-buy call?

Not IT alone. IT should check security, data access and integration, and should have a real veto on those. But what the tool must do belongs to the business owner of the workflow, and someone has to sit between the two and translate. We call that the product function, and we explain it in our post on why IT should not own AI on its own.

Your job as CEO is narrower: insist on the order. No vendor meeting before the What is written down. No build approved without a named owner and a stop date.

What should you do this month?

Pick the AI idea your team is most excited about and run the six-step test on it. Then list every AI tool and project you are paying for and sort each one into configure, buy or build. If anything in the build column fails the four build questions, put it on the agenda for your next leadership meeting.

If you want an outside view on which of your AI ideas belong on which path, Journey offers a free CEO AI audit to help you see where you stand and what to do next.