Build vs buy: How AI is changing how we think about managing risk

There are two ways to answer your board when they ask what you are doing about AI. Vertical AI software, or your own applications built with agentic AI. Both check the same box. Only one gets you out of the vendor fragmentation race.

Off the shelf software was always designed for the 80 percent. It has to be, because it is sold to everyone in an industry and it can only encode what those companies have in common. The remaining 20 percent is the part that makes your business yours, and it gets handled with external workflows, integrations, spreadsheets and headcount. That was a sensible trade for as long as building was slow and expensive, and adding AI features to the tool does not change any of it.

As the cost of building custom software becomes dramatically cheaper with AI, it's worth revisiting the build vs buy decision. We're at the point that the equation has rebalanced. The biggest obstacle left is no longer technical. It is the change of mindset traditional businesses have to make.

01Buying was always a risk decision

Building software took engineers, and most companies outside tech had no experience hiring them or running a technical team. Buying moved that risk to a vendor. What made that the right call:

1. Timeline. Custom took far longer to stand up than buying off the shelf.
2. People. Running it took a large specialised team you had to hire and then keep.
3. Risk. If it failed the business was left struggling.

Cost was a derived factor, mostly what it took to manage the first two.

None of those are the same any more. A first version takes about six weeks and production about a quarter, depending on how complex the tool is. A lean team builds it and runs it. The risk drops because AI gives you the confidence of a multi disciplined bench on call.

What has not moved is the risk appetite. Most companies are still pricing the old risk. Time will tell if we are ready to give up the "nobody ever got fired for hiring IBM" mindset we trained the mid market and enterprise IT function on.

02Our case study: a Middle Eastern agricultural commodities business

They trade grain out of the Black Sea into ports across the region. Every shipment travels on a stack of documents that all have to agree with each other before a bank will release payment, and someone reads them by hand looking for mismatches. A wrong date or a party name spelled two ways is enough to stop the money.

They were evaluating software to do that comparison for them. This is a common problem in this kind of business, and there is off the shelf software sold to exactly these companies, which is what anyone would reach for first. Several hundred thousand dollars a year.

03What we built instead

An operator application. You upload the documents, the AI does the comparison, and a person works only the exceptions. Multiple desks with completely different jobs run on the same system, because these documents pass through several departments for sign off before anything is approved.

04Use case one: Comparing one contract to another

This is the contract desk's problem. Draft against signed, or two back to back contracts that are supposed to mirror each other, where somebody has to confirm nothing moved between the version that was agreed and the version that got signed. Upload both and every difference comes back numbered, with the wording either side and a summary of what changed, and each one can be located in both documents at once.

Every screen below runs on data we generated for the article. Names, parties, vessels, banks and figures are invented, and no customer data appears anywhere in it.

05Use case two: Checking a shipment against its letter of credit

Operations' problem, and a harder one, because the credit is the bank's own list of conditions and the checks have to come out of that specific credit rather than a template somebody configured once. You upload it, the AI reads it and writes the checklist itself, and the operator corrects anything it read wrong before accepting. The supporting documents go in next, usually as one PDF with everything inside it, which the system splits apart and classifies. Then it runs, and what comes back is split three ways: the checks that passed, the ones it is confident are wrong, and the ones it is unsure enough about to want a person to look.

Different desks, different workflows, one system. On a subscription each of those is another module, another negotiation, and another set of things the vendor does not quite do the way you do them.

This is the kind of use case no off the shelf product gives you out of the box. It is heavily custom to how this organisation works: their checks, their documents, their sign off chain.

06How can you get started

The hardest part is starting. We began building our own operating system less than six months ago, and most of what we know about what this takes came from running the company on it rather than from planning it.

If you are doing this yourself, pick something new over something you are replacing. Software you were going to buy anyway is the cleanest place to build, because there is nothing to unpick, no integrations to preserve and no migration, so a build and a purchase compete on even ground. Replacing an application you already run is harder, since something is already there holding data people depend on, and we will cover that properly in a future issue.

07Two ways to tick your board's AI checklist

Talking to more than a hundred companies over the last six months, three approaches come up, and they get used interchangeably even though they are quite different.

AI enablement is your people using AI tools to do their own jobs faster. Every company needs it and nobody argues about it, so it is not really a decision.

Vertical AI is external software that now has AI capabilities in it. An MCP server, a chatbot, AI workflows, summaries written for you, essentially AI wrapped around a product. You are still renting, still integrating, and still working around the parts that do not fit.

Applications are what this issue is about. Building for your own workflow is how you simplify the stack over time and end up with something personalised. You might not have a chatbot or an MCP server on day one, but do you even need one? It already does exactly what you need, because it was built around how you work.

08FAQ

Isn't buying much faster than building?

No. Off the shelf was never personalised to you. It ships what a whole industry has in common, and you still have to configure it for how you work, onboard people, train them, and build the integrations into everything else you run.

On the build side you can have a first working version in four to six weeks and a hardened production version in a quarter. The timelines are not far apart. If what you are looking at is very large, break it into two or three smaller pieces, because a CRM or ERP implementation running into a year is completely routine and nobody calls that fast.

Vendors ship improvements constantly. Isn't that impossible to keep up with?

You're probably using 20 to 40 percent of what your vendors actually provide. Most companies have an enormous amount of duplicated capability across the stack, so much so that finding it and flagging it to finance teams has become its own category of software.

With software built for you, you only build what you need, so there is nothing in it you are not using. In practice you also ship changes faster than a vendor's upgrade cycle delivers them.

If you want to work out whether your version of this is a build or a buy, reach out.

Tarush