Build vs. Buy AI
We build custom AI for a living, and we tell clients to buy a product more often than you would expect. Here is the reasoning we use, so you can run it yourself before you talk to anyone, including us.
Buy the ordinary, build the specific
There are mature AI products for most common business problems now, and they are usually cheaper and faster than anything custom. If your process looks like the standard version of that process, buy the product and move on. Nobody has ever won in their market by having a better internal expense tool.
Building earns its keep in one place: where the way you do the work is genuinely yours. The pricing logic your team argues about. The document nobody else receives. The system your industry runs on that no vendor has bothered to integrate with. Those are the places a product either cannot go or goes badly, and they are usually close to the reason customers pick you.
The most common right answer is not one or the other. It is a product handling the easy majority of the work, and something custom handling the expensive remainder it hands back.
Run these before you shortlist anybody
Most of them can be answered in an afternoon by the people already doing the work.
Does a mature product already cover this?
Not a product that demos well, one with real customers doing what you need at your scale. Ask a vendor for two references who look like you, then ask those references what still gets done by hand.
Buy if yes and the references hold up. This question ends most build conversations, correctly.
Where does the time actually go?
Sit with the person doing the job for an hour. The step leadership assumes is the bottleneck usually is not. It is rarely the data entry everyone points at, and often the checking, matching, or chasing that follows it.
Build if the expensive step is the one products treat as an edge case. That is the whole argument in one line.
Will it connect to the systems you actually run?
Ask specifically, by system name and version. A vendor's integration list is written for the mainstream, and plenty of good companies run something older, industry-specific, or heavily modified. If your team currently bridges two systems with a spreadsheet, say so out loud during the demo.
Build if the connector does not exist, or exists only as a roadmap item. Roadmap is not a connector.
What does three years cost, both ways?
On the buy side: subscription, per-seat or per-transaction fees at your projected volume, implementation, and annual increases. On the build side: the build, hosting and model usage, and maintenance, which is a real number and not zero. Then add the piece most business cases quietly leave out, the staff time spent on whatever the product does not cover.
It depends on volume. At low volume a subscription usually wins. At high volume over three years it often does not, and the crossover is worth calculating rather than assuming.
Is this close to what makes you good?
Automating something generic frees up hours. Automating the thing you do better than your competitors compounds, because it gets better as you use it and nobody can buy the same advantage off a shelf.
Build if it is close to your edge. Buy if it is plumbing that happens to be annoying.
Who owns it in eighteen months?
The honest failure mode for custom work is not that it does not work. It is that it works, the person who understood it leaves, and nobody touches it again. A product has a vendor with an obligation. A custom system needs a named owner inside your organization.
Buy if you cannot name that person. This one disqualifies more build projects than budget does.
The line moved, and it is worth re-asking
If you priced a custom build two or three years ago and decided against it, the arithmetic has changed enough to be worth redoing.
The parts that used to dominate a custom AI budget are largely gone. You no longer train your own model. You no longer build a template per document type and maintain it every time a supplier changes their layout. Current systems read a document they have never seen before, which is what makes the messy long tail of real business documents economic to handle for the first time.
What is left is the unglamorous part: understanding the workflow, connecting to your systems, handling exceptions, and proving accuracy on your data rather than a demo set. That work has not gotten cheaper, but it is a much smaller share of the total than it used to be.
A rough guide
Count your rows. If most land on the left, buy something and spend the attention elsewhere.
| Buy a product | Build custom | |
|---|---|---|
| The process | Looks like everyone else's | The difference is the point |
| Your systems | Mainstream, supported connectors | Older, industry-specific, or customized |
| The hard step | Covered by the product | Treated as an edge case by every vendor |
| Volume | Low enough that per-unit pricing is comfortable | High enough that per-unit pricing compounds against you |
| Strategic weight | Plumbing | Near your competitive advantage |
| Ownership | Nobody inside can own a system | You have a named internal owner |
| Timeline | Needed next month | A quarter is acceptable for a better fit |
A split result is not a failure of the exercise. It usually means buy for the standard flow, build for the exceptions.
Four things to insist on
You own the code. Not a license to use it. Ownership, in writing, so a future disagreement with your builder is a business inconvenience rather than an operational emergency.
It runs in your accounts. Your cloud, your keys, your off switch. If it can only run on the builder's infrastructure, you bought a product with extra steps.
Accuracy is proven on your data first. Before scope, before contract. Any builder confident in their approach will test on a real sample of your documents and show you the number, including the cases it got wrong.
The handover is scoped as work. Documentation, monitoring, and time with your team, written into the engagement rather than promised at the end. A handover that is not scoped does not happen.
The ones that come up next
You build custom AI. Why would you tell us to buy?
Because a client who bought the right product and got their hours back tells other people about it, and a client we talked into an unnecessary build does not. It is also faster to say no on a thirty-minute call than to discover the mismatch in month three, for both of us.
What if we do not know which of our problems to start with?
That is a different question from build-or-buy, and it comes first. An assessment scores the candidate projects across your business and comes back with a ranked list, including which of them should be solved by buying something.
AI opportunity assessment →Can you help us evaluate products we are already considering?
Yes, and we do. Sitting in on vendor demos and asking the technical questions on your behalf is a genuinely useful use of a few hours, especially the questions about what happens to the cases the product does not handle.
How much maintenance does custom AI really need?
Less than a traditional application, more than zero. Model providers update, your source systems change, and your own process drifts. Budget for it as a small ongoing line rather than assuming a finished project stays finished.
Is there a middle path?
Usually, and it is the most common outcome. Keep the product doing what it does well, build for the part it hands back. That tends to be both cheaper and less disruptive than replacing a working system to solve a problem at its edges.
- Featured by Apple in Best New Apps & Updates (LilSense)
- Serving collegiate and professional programs, including an NCAA national championship team
- Founded Wisconsin's longest-running AI practitioner community (meeting weekly since 2024)
- Co-hosts the AI Leadership Breakfast Forum with Steve Cretney (EVP, Colony Brands)
Run the six questions with us
Thirty minutes on your specific workflow. If the answer is buy something, we will tell you what to look at.
Book a Call