Build vs Buy AI: Decision Framework, Costs and Exit Plan

A practical platform comparison

For the concrete choice between a visual workflow platform and custom code, use the n8n vs custom AI agents decision matrix. It includes a worked, hypothetical cost-per-completed-task calculation and a handover test. The core question remains whether the workflow is a commodity or a source of 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. The way to find out which one you have is to test it rather than ask: a one-day acceptance test runs the repository, the tool definitions, the evaluation set and the run history without the builder in the room.

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.

Which version of the question are you actually asking?

"Build versus buy" arrives in several shapes, and they are not the same decision. Naming which one you are in shortens the argument by about a week, because each shape has a different decisive question and a different person who has to answer it.

Two of those rows deserve a sentence of their own. Conversational AI is the case where buying is right most often, and the exception is easy to spot: a hosted assistant handles intent, tone and small talk better than anything you would build this quarter, and it is the escalation rules — who gets the customer who is already angry, what happens when the customer turns out to be right — that decide whether the purchase holds. If those rules are your advantage, you are buying the conversation and building the decision. The investment framing changes the document rather than the decision: a proposal that leads with a first-year licence price invites a comparison of line items, and the comparison that decides is three years long, includes the human handling of every case the system declines, and starts from what the manual process costs per month while it stays manual. The arithmetic, with the five lines a quote leaves out, belongs before the proposal is written rather than after it is questioned.

What does the recommendation look like when it goes to a budget holder?

Three sentences, each of them checkable by somebody who was not in the meeting.

1. The decision and its subject, named: "we build the quote engine, we buy document intake." A recommendation without a subject cannot be argued with, only approved.
2. What each path costs over three years, with the exception line included and denominated in finished work rather than licences — a monthly figure the finance team can put beside the process's current run-rate.
3. The owner and the review date. The failure this document exists to prevent is not choosing wrongly; it is choosing without anyone accountable for revisiting it.

If the honest answer is "not now", that belongs in the document as well, together with the cheapest way to keep the option open: the two-week test below is a smaller line item than the procurement cycle it replaces, and it produces the three numbers that turn the next version of this proposal into an argument about evidence rather than about strategy.

Is it cheaper to buy AI software than to build it?

Usually yes, and for a reason that has nothing to do with the licence fee: the licence is the small line. The deciding number is fully loaded cost per completed task — every attempt, retry and minute of human review, divided by the work that actually finished — and for most processes the human handling of declined cases runs an order of magnitude above the software. Buying wins when the process is ordinary; building wins when the same measure improves because the exception path is yours. The unit that makes the comparison honest is worth computing before either quote is read.

Should we build on an AI platform or own the layer underneath?

Own the tool boundary and the evaluation set; rent almost everything else. An agent purchase is four boundaries rather than one, and only two of them decide whether the system stays yours: who writes the typed tool definitions, and who can prove that a model change did not break the workflow. Platforms are the right answer for the read-only, commodity half of that surface, and the wrong answer for the writes. The four boundaries, and which to own is the longer version of that split.

What belongs in a build-versus-buy proposal?

Three sentences and one paragraph. The decision and its subject; what each path costs over three years including the exception line; the owner and the review date. The paragraph is the risk section: what happens if the answer was wrong, and what the exit costs. Proposals that open with a first-year licence price invite a line-item comparison, which is the one comparison this decision should not be reduced to.

What about conversational AI specifically — build or buy?

Buy the conversation, build the decision. A hosted assistant handles intent, tone and small talk better than anything a single team ships this quarter, and the part that determines whether the purchase holds is the escalation rules: who receives a customer who is already angry, what happens when the customer turns out to be right, and what the assistant is forbidden to promise. If those rules are what customers pay you for, they belong in your code rather than in a vendor's configuration screen.

How long should the decision itself take?

Two weeks of engineering, and it should produce three numbers rather than a prototype: the share of cases handled without human review, the cost per run, and the cases where the system is confidently wrong. That is the cheapest artefact in the whole process, it is smaller than the procurement cycle it replaces, and it is the only thing that turns the next version of this argument into a conversation about evidence.

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.

One qualification, because it changes the shape of the answer without changing its logic: if what is being chosen is an agent platform rather than a workflow tool, the purchase splits into four boundaries — the tool surface, the control loop, the model and the evaluation set. The model is a near-certain buy; the two worth owning are the tool boundary and the set of cases that proves a change did not break the workflow. If you want that analysis run against your own processes rather than in the abstract, send a brief describing the three processes you would be measurably worse at without — the reply is the analysis, not an invitation to a call.