Build vs buy an AI sales system: the decision table

Build if you clear three capacity gates and have at least one reason to build; otherwise buy. In MIT Project NANDA’s 2025 research across 52 organisations, customised tools sourced through external partners reached deployment about 67% of the time, against about 33% for internally built tools. Three gates decide whether you can build; four decide whether you should.

At a glance — three capacity gates, all of which must say build:

• Engineering capacity: two dedicated engineers for twelve months, one on call, neither on the product roadmap.
• Time to first conversation: you can wait six months or more.
• Maintenance owner: you can name the person and the budget line today.

And at least one reason gate, any of which is enough on its own:

• Economics: bought-outcome spend would exceed roughly 3× the fully loaded cost of that build team.
• Integration surface: your system of record is bespoke and has no public API.
• Compliance exposure: legal or a regulator will not let any processor hold conversation content.
• Product differentiation: the way your agent qualifies, prices or triages is itself the thing customers pay you for.

Disclosure: LeadsNow sells the buy side of this decision. The thresholds below are our rule, not a survey result, and a reader should assume they are set where they suit us until they have checked them against their own numbers.

The seven gates that decide build vs buy

Criteria before comparison, or the comparison is theatre. An AI sales system is not one product: it is a conversation model, a script and eval set, a telephony and messaging path, a calendar, a CRM write-back, and a set of consent records. Any competent engineering team can stand up a working demo of that in a fortnight. The demo is not the decision. The seven-gate rule: three gates say whether you can build — engineering capacity, time to first conversation and maintenance owner — and all three have to say build, because each one on its own is enough to sink a build that was otherwise correct. Four more say whether you should — economics, integration surface, compliance exposure and product differentiation — and any one of those four is sufficient on its own. The gate that fails is almost never capability — it is the one that says who keeps the thing working in month fourteen, after the model has changed, the offer has changed and the engineer who wrote it has moved teams. Where AI fits into a business that already has customers and pipeline is the wider question covered in our AI for business overview; this page is only the build-or-buy fork.

Build vs buy an AI sales system: the decision table

Thresholds, not adjectives. These cut-offs are our rule rather than a survey result — argue with them, but argue with numbers. One of them needs its bias stated out loud: the 3× in the economics gate is a risk margin for schedule overrun and staff turnover on the build, not a measured multiple, and setting it at 3× rather than 1× makes building harder to justify. We sell the buy side, so that margin runs in our favour. If you think it is self-serving, run the gate at 1.5× and see whether your answer changes; if it does, the economics gate was never the thing deciding it.

Ownership is the gate teams skip, and it is the one that decides the outcome — the same argument we make about bought systems in who should run your AI appointment setter. Buying does not remove the owner; it removes the on-call engineer.

What it costs to maintain an AI sales system we built ourselves

This is the line item that is missing from nearly every build case, so here it is end to end. The unit is engineer-days a year in steady state — after launch, doing nothing new.

Substitute your own day counts — the column above is a template, not a benchmark, and the only externally sourced figure in it is the model-retirement window. The build is a project; the maintenance is a job, and 96 engineer-days a year is a job nobody has been hired for.

Costing build and buy on the same basis

Here is where this comparison is usually rigged, including by people who sell what we sell. The build gets a whole-life ledger — salaries, ramp, maintenance, opportunity cost — and the buy side gets quoted as a clean fee, as though a vendor fee were the entire cost of buying. It is not. A bought AI sales system still consumes your people’s days, and it carries costs that never appear on any ledger at all. Put the two on the same basis or do not put them side by side.

And four costs of buying that are not days at all, and are the honest case against us:

• You own no asset at the end. Ten years of building leaves a system on your balance sheet. Ten years of buying leaves ten years of invoices and a renewal.
• No capability transfer. Your team does not learn to do this. The second time you need it, you are in exactly the position you are in now.
• The spend never ends. A build has a capital hump and then a maintenance floor. A bought outcome has no terminal point, and the total crosses the build’s total at some year — work out which year before you sign, not after.
• The knowledge leaves with the supplier. What the agent learned about your buyers — objections, pricing sensitivity, which segments never convert — sits with whoever ran it. Contract for transcript and eval-set export at the start or accept that you are renting your own market knowledge.

Our commercial model is outcome-priced: a share of the sales generated, or a fee per booked qualified appointment. That changes who carries delivery risk. It does not change a single line in the table above, and it does not make our cost per call the lowest available — it is usually higher, because qualification is tighter before anything reaches your calendar. The number to compare is closed-deal return, not cost per call, and it is your number to work out rather than ours to assert.

When building is genuinely the right answer

There is an honest case for building, and it is not the one usually made. It is not cost, and it is not “we want to own our data” — a processor agreement handles that. This is the product-differentiation reason gate, and it is the one most likely to be missed by a scoring exercise. Build when the conversation is the product: when the way your agent qualifies, prices or triages is itself the differentiator you sell, and handing it to a vendor means handing over the thing customers pay you for. Build when the system of record genuinely has no integration path. Build when a regulator, not a preference, forbids third-party processing. And build when you have already run the sequence at volume with something bought, so the eval set exists before the engineers do.

Who each option is wrong for

Build is wrong for a company whose AI ambition is a sales channel rather than a product; for teams whose engineers also own a customer-facing roadmap; and for anyone who cannot name the on-call owner in the meeting where the build is approved. If the business case rests on saving vendor fees, check it against the 3× test above before writing it down.

Buy is wrong for organisations whose legal team will not permit a processor to hold conversation content, whose system of record has no API, or whose qualification logic is a trade secret. It is also wrong where nobody internally will own the numbers — a bought system with no owner fails the same way a built one does, just faster and with a contract attached. And it is wrong for anyone who needs the capability itself: buying produces a working channel and no owned asset, no engineers who now know how to do this, and a spend with no end date, while the knowledge the agent accumulates about your buyers sits with the supplier unless you contracted otherwise. A business whose plan is to run this themselves in three years should not buy for three years first — it should buy for one and build against the eval set. What buying actually looks like operationally is set out on our AI sales agents page.

Hybrid — buy the platform, build the layer on top — is wrong for teams who need one accountable party. It is also the option with the thinnest evidence: NANDA recorded hybrid build-buy as a distinct structure but reported insufficient data to quantify it, so anyone quoting a hybrid success rate at you has made it up.

How long until the first real conversation?

Timeline is a gate, not a preference, because sponsors change. NANDA found that top-performing mid-market companies averaged 90 days from pilot to full implementation, while enterprises — defined there as firms above $100 million in annual revenue — took nine months or longer, despite running more pilots and assigning more staff. The same report found that 60% of organisations evaluated enterprise-grade AI tools, 20% reached pilot and just 5% reached production. If your board has given you two quarters, the build timeline and the approval timeline are the same length, which means the build has no slack at all.

What the 67% vs 33% number does not prove

Both headline numbers in this debate are weaker than the way they get quoted, and a decision this size deserves the caveats. NANDA’s 67%/33% split comes from an interview sample of 52 organisations with self-reported outcomes; the authors write that the difference “may reflect organizational capabilities rather than implementation approach alone” and that correlation does not prove causation. They also note they observed far more build initiatives than buy initiatives, so the denominators differ. Separately, the widely repeated 80% failure figure is not RAND’s finding either. RAND’s 2024 report writes “By some estimates, more than 80 percent of AI projects fail—twice the rate of failure for information technology projects that do not involve AI”, and its footnote for that sentence points to Jeremy Kahn’s 2022 Fortune article, not to any RAND measurement. RAND’s own contribution is 65 interviews with experienced data scientists and engineers and five root causes, all of them organisational rather than technical. Two of the most-quoted numbers in this argument are a self-reported sample of 52 and a figure repeated from a magazine article in a footnote: use them to frame the decision, not to win it. Our own position is disclosed rather than hidden — LeadsNow sells the buy side, has 50,769+ AI-booked sales appointments since 2017, and publishes how its headline figures are calculated, including that its 7× average sales lift is an average and that the median client sits closer to 4×. Neither of those figures says anything about whether you should build.

Build vs buy: questions people ask before they commit

Should I build or buy an AI sales system?

Build only if you can staff it, wait for it and name its owner, and you have at least one reason to build; otherwise buy. The published evidence leans towards buying: MIT Project NANDA’s The GenAI Divide: State of AI in Business 2025 found externally partnered, customised tools reached deployment about 67% of the time against about 33% for internal builds, in a sample of 52 organisations with self-reported outcomes.

Is it cheaper to build an AI SDR in-house?

Only above the 3× threshold, and only if you cost the 96 steady-state engineer-days a year as well as the build. Published per-meeting and per-opportunity benchmarks for human SDR teams are largely sitting behind gated vendor and analyst reports, so we have not quoted one here; use your own cost per qualified meeting from the last four quarters as the input instead, and read the AI for business overview for where the spend usually sits.

What happens when the model we built on is retired?

You migrate, on the provider’s schedule rather than yours. Anthropic’s model deprecations page commits to at least 60 days’ notice of retirement for publicly released models and publishes dated retirement schedules. That is a reasonable notice period and still a hard deadline: your prompts, guardrails and eval set have to be re-run and re-tuned against the replacement inside it.

Do most AI projects actually fail?

The honest answer is that the number everyone quotes is not a measurement. RAND’s The Root Causes of Failure for Artificial Intelligence Projects (Ryseff, De Bruhl and Newberry, August 2024) repeats “more than 80 percent” from a 2022 Fortune article by Jeremy Kahn, cited in its own footnote; RAND’s own research is 65 practitioner interviews identifying five root causes, which are about problem definition, data, and sustained sponsorship rather than modelling.

How many engineers do I need to build an AI sales system?

Two, ring-fenced for twelve months, with one on call — and then roughly 0.44 of an engineer indefinitely. If the plan is one engineer at 50% time, you are not building an AI sales system; you are building a prototype that a quarter-end will kill.

Can we buy now and build later?

Often, yes — and note that we sell the first half of that sentence, so weigh it accordingly. The argument for it is that it produces the asset a build needs most: a labelled eval set of real conversations and a measured baseline. The argument against it is that a year of buying is a year your team does not spend learning to do this, and the eval set is only yours if you said so in writing. Agree portability at contract time — transcript export, consent records and CRM field ownership — and check it against your own risk requirements using the AI outbound compliance checklist for enterprise.