Build vs. buy AI: only the build got cheaper
Building AI got cheap, running it didn't. When building your own AI pays off and when buying is smarter, with a decision table for the leadership team.
Build vs. buy for AI is a new calculation now, because building got cheap and running didn't. Most companies still reach for the purchase order, one license after another, because off-the-shelf software feels safer and building in-house sounds like shadow IT. I see it differently. At SUMAX the team and I now build systems I wanted for years, without endless licenses and without years of development, and between them and the AI models sits a layer of our own that lets us switch models any time. Building only pays off when several applications share a capability and someone runs it. If either is missing, buy.
AI flips the math, but only for the build.
The question used to end with buying almost every time. A system of your own would have taken years and a dev team, so companies bought license after license and bent their workflows to fit the software. Today an in-house tool takes a fraction of that time. Building never means training your own model. It means your own applications on top of existing AI models, often combined with purchased tools through interfaces you control.
Only the building got cheaper, though. Running the system costs what it always did: access, permissions, security, errors, changes. If you build, you answer those questions yourself, every month. So two questions decide it. Do several applications need the same AI capability? And can the company run, maintain and secure it for years? Never price a build without the operations.
Building only pays off when several applications share a capability and someone runs it.
Compare products first and you're comparing feature lists.
Before any product comparison, pin down what the workflow needs: which inputs it takes, which data sources belong to it, who signs off and where the result goes. That list is short. Only with it can every offer be measured against the same work instead of its own feature list.
A trial with a real task from your own day-to-day, with real data and the real sign-off step, tells you more than any demo. It surfaces what demos hide: the export someone cleans up by hand, the data source the product can't reach. If the task is narrow and a vendor handles it well in the trial, buy.
Both paths lock you in.
Buy AI software and you depend on the vendor's interfaces, pricing and roadmap. If they change the pricing model or drop a feature, your workflow changes with it. With AI that risk is higher than with most software, because the models underneath change fast.
Build and you depend on your own people, their know-how and their time. If that know-how lives in a few heads instead of one place, every vacation becomes a risk. Which dependency you can live with depends on how close the workflow sits to the business. Scheduling or standard reports are fine on a product someone else maintains. Keep control where the company makes its money.
Development is the smaller cost.
Costs run over the whole lifetime of the system, so the decision belongs at one table with IT, the business side and leadership. The ongoing costs are operations, maintenance, adapting to new models and training. With sensitive data, privacy rules and the EU AI Act come on top: where the data goes, which model processes it and how its use is documented.
One question gets skipped almost every time: how do you get out again, and what do you take with you? Exit is cheapest at the start, and that's exactly when nobody wants to talk about it. Settle the exit before you sign, whether you buy or build.
Build for the shared capability.
At SUMAX I chose a layer of our own between our applications and the AI models. Several applications use it to reach models, data and recurring functions. The model can be swapped without rebuilding the applications on top. If a vendor gets more expensive or worse, we switch. Every call is booked with its cost.
The order mattered to me: first the foundation for everyone, meaning users, permissions and access, then the tools for individual tasks. Before that, process knowledge was spread across older systems and lists. As of this revision in October 2026, a five-figure number of AI calls a month runs through that same layer, the large majority of our people use our own tools every month, and several purchased tools have been replaced by our own. The build pays for itself because many applications share the same capability. Build the layer before you build the second tool.
Build or buy: the decision table.
| Question | points to buying | points to building |
|---|---|---|
| How many applications need the same AI capability? | one or two | several |
| Who runs the system after launch? | nobody in-house | someone in-house, for years |
| How narrow is the task? | narrow, a vendor handles it well in a trial | spans departments and data sources |
| How close is the workflow to the business? | side task like scheduling or standard reports | core of what you sell |
| What happens if the vendor changes price or model? | the workflow can absorb it | the workflow stops |
| How many contracts already cover similar tasks? | none or one | many, with scattered data |
If the first two rows say buy, the decision is made, whatever the rest says. The last row describes the opposite case. A company that buys a separate tool for every use case already has the shared capability, just spread across many vendors, with no shared view of cost or quality.
Not every company should build.
Our decision is no recommendation for everyone. A company with one or two AI applications, or with nobody to look after a system once it's live, is better off buying and putting the effort into requirements, testing and training.
For me, building is the better choice once several applications share a capability and someone owns the operation, and not before. List every AI tool and contract your company has, and next to each, the capability it uses. Where a capability shows up twice, that's your decision point. How we set this up is in The transformation at SUMAX.