Build vs Buy AI: Buy the Commodity, Build the Advantage

The question behind the question

Buy the commodity, build the advantage. That is the entire position, stated first so you can disagree with something specific rather than with a mood.

Build-versus-buy for AI arrives in most companies as a spreadsheet: platform licence, implementation fee and support on one side, two engineers for two quarters on the other. That spreadsheet matters, and it is the second question. The first is whether the process you are about to automate is a source of advantage. If it is, buying a platform means renting your differentiation — you keep the revenue, someone else keeps the mechanism. If it is not, building it is a hobby, and hobbies in production come with a pager.

Buy when the process is table stakes and the vendor's scale beats yours. Build when the process is what the customer pays for, because buying a platform for that process means renting your differentiation.

I build AI workflows for enterprises, and I have argued clients out of bespoke work about as often as into it. What separates the decisions that aged well is not a technology choice: somebody in the room could say, without hesitating, which three processes the company would be measurably worse at than its competitors if it lost them tomorrow.

What does renting your differentiation actually cost?

Three mechanisms do the damage, and none of them appear on the licence invoice.

Roadmap coupling. A platform's abstraction is designed for the median customer across its whole customer base. Your process now changes on their release cadence, in their priority order. If your advantage is responding to a pricing change faster than a competitor, you have handed the clock to a vendor with a few thousand accounts and a quarterly release train.

Configuration is not an asset. The workflows you assemble inside a platform are licence-specific artifacts. They cannot be sold, transferred or depreciated. A bespoke build, even an unglamorous one, is an asset with a balance-sheet existence.

Data asymmetry. Every run you push through a vendor platform teaches the vendor something about how your process works. Whether that data is aggregated, whether it trains anything, and whether your operating pattern becomes a benchmark a competitor can buy are contract terms, not technical facts. In most templates I read, they are silent, and silence favours the vendor.

Who owns the code on the third anniversary?

The two-way framing hides the option most mid-market firms actually take: pay someone else to build it. A vendor build is a different purchase from a platform licence, and it is right when the process is differentiating but not permanent — you need the mechanism now, and you will not staff an engineering group to hold it for a decade. It is wrong when the contract is quiet on four things: repository ownership, the tool and schema definitions, the evaluation set, and your right to hire the people who did the work.

If those four are yours, you have bought time, which is a legitimate purchase. If they are not, you have bought a subscription with a project-shaped invoice, and the renewal price is set by whoever holds the code.

What does each path cost over three years?

Compare cost lines, not first-year quotes. The line that decides the answer is usually change requests in year two.

On the bespoke builds I ship, the differentiating layer is usually 2,000 to 4,000 lines of TypeScript with two to four typed tool definitions, plus an evaluation set of 60 to 120 recorded cases from real traffic. That is a six-week build for one competent engineer, not a six-month programme; the figure comes from my own delivery logs, and it is why I distrust build estimates that begin with a headcount. Against it, a platform at $2,000 a month is $72,000 over three years before a single hour of implementation — arithmetic you can do from the vendor's written quote in your inbox. The figures I cannot supply are yours: the fully-loaded cost of the role doing this work today, and what a week of process latency costs you.

The recurring line most teams omit is cost per run, and at volume it settles the decision alone. A feature comparison will not tell you whether the tenth thousand run of the month is cheaper than the first, which is the number your finance team will ask for. That needs a per-token cost model that survives a finance review, built in an afternoon from your provider's published prices.

Which of four tests does the process fail?

Two passes out of four is not enough. The owner test is the one executives skip, and the one that decides whether the build is alive in year three or merely still invoiced.

When is buying clearly the right answer?

Buying is not a compromise when the process is identical across your competitors, when volume is low enough that per-run cost is a rounding error, when a shelf product is good enough that your version would be a ten per cent improvement, and when the process sits adjacent to your advantage rather than inside it. Payroll onboarding, standard document intake, meeting notes, tier-one support triage and expense review all live in that category for most firms I work with, and building any of them postpones the harder question of where the company is actually better than its peers.

Buying is also the cheapest way to learn what your process actually is; the configuration will not travel with you, but the knowledge will.

When is a bespoke build genuinely justified?

Build when the process encodes knowledge that exists nowhere else — pricing judgement, underwriting rules, the way a specific account manager decides what to escalate — when the output is literally what the customer buys, when volume makes cost per run a visible P&L line, and when you can name its owner. Those conditions are rarer than the number of AI pilots suggests. A build is a permanent commitment to maintain one thing, and the only honest question is whether this particular thing is worth maintaining for a decade.

What is the cheapest test before you commit either way?

Spend two weeks and one engineer before you sign anything. Build the thinnest vertical slice of the process — one tool boundary, one prompt, one database write — and run it against fifty real cases pulled from last quarter's traffic. The result you want is not a working system; it is three numbers: the share of cases handled without human review, the cost per run, and the cases where it is confidently wrong. An evaluation set of sixty to a hundred recorded cases is the only artifact that survives either decision, because it is what you hand a vendor to hold them to a result and what you hand an engineer to tell you whether a model change broke something. Two weeks costs less than a procurement cycle and replaces an argument about strategy with a measurement.

What has to be in the contract either way?

That last clause rarely appears in a standard agreement, and it should: an unrequested model upgrade can change the behaviour of a process your revenue depends on, and only your own recorded cases will tell you.

Decide the process first, the platform second

Start by naming the three processes you would be measurably worse at than your competitors if you lost them tomorrow, and treat only those as build candidates. Everything else should be bought quickly, with a defined exit and a metering definition you can explain to a CFO without notes. Run that analysis before the first vendor meeting, because a good sales engineer can make almost any process feel like a commodity in ninety minutes, and the process that genuinely is not will feel commoditised too, right up until the day you cannot change it without a statement of work. Write the decision down with an owner's name and a review date, and revisit it annually: the answer changes when your process changes, not when the market does.