Do we build or buy the AI sales system?

The weekend changed the question

Two years ago “should we build our own AI sales system?” was a fantasy question. Now it’s a reasonable one: a capable RevOps engineer with a model API, a data source, and a CRM connection can produce something genuinely impressive by Monday — an org chart, a research brief, drafted messages, suggested Salesforce updates, on demand.

So the honest framing isn’t can you build it. You can. It’s which problems do you want to own — because the prototype and the system share a demo and almost nothing else. This post is the math, from a vendor with an obvious stake, argued so it holds up anyway: the decision rule at the end cuts both ways.

---

At 4:00 on a Friday, the prototype looks finished. At 9:12 on Monday, an AE tries it on a live account: the “decision maker” left in June, the initiative in the email came from a two-year-old press release, and the CRM suggestion is about to overwrite a current note with an older one. Nothing went unusually wrong. The prototype met a real account.

1. What Monday actually revealed

Which problems appeared the moment real accounts arrived?

Each of Monday’s embarrassments is not a bug. It’s a permanent workstream introducing itself:

Identity resolution. The CRM, the data provider, and LinkedIn disagree about who holds which job. Deciding who’s right — continuously, at scale — is a discipline whole companies are built on.

Research freshness. Research ends in dated, falsifiable claims or it ends in confident fiction. Keeping claims current across every account is the difference between a system sellers trust and one they silently route around.

Model drift and evaluation. Models change under you; prompts that worked degrade quietly. Without an evaluation harness, you find out from a seller — or from a buyer.

CRM edge cases. Duplicates, custom objects, permissions, the merge that attaches the right update to the wrong record. Write-back is where “mostly works” makes the record worse at machine speed.

The unglamorous rest. Connectors expire. Providers change terms. Someone owns alerts, onboarding, support, and the backlog — which live accounts refill weekly, forever.

2. The real invoice

What does owning V12 cost?

Price the build the way a CTO would, not the way the demo feels. The prototype line-item is an engineer-weekend and an API bill. The production line-items are the five workstreams above, staffed permanently — call it the fully-loaded cost of the small product team your best engineer will end up leading — plus the cost nobody invoices: that engineer’s next-best project, and the accounts your sellers work shallow while the internal tool matures.

And buying doesn’t zero your effort, which an honest comparison admits: you still define your motion, connect your systems, and own your judgment. The difference is starting from maintained software instead of staffing the maintenance — the backlog becomes someone’s full-time job that isn’t yours.

Illustrative year

The roadmap after the demo

The same working prototype, twelve months down each road.

Build

1. Mo 1

   The demo wows; a pilot team starts using it.

2. Mo 3

   Identity resolution becomes the sprint. Then the quarter.

3. Mo 5

   Research freshness and an eval harness join the backlog.

4. Mo 8

   CRM edge cases; the first silent-overwrite incident; write-back gets an approval layer — rebuilt in-house.

5. Mo 12

   It works — staffed by your best engineer, permanently.

Buy

1. Wk 1

   Configure the motion: accounts, personas, plays.

2. Wk 2

   Connect the CRM and inboxes; sellers on live accounts.

3. Mo 2

   The edge cases arrive anyway — into someone else's backlog.

4. Mo 12

   The engineer shipped your product's roadmap instead.

What V1 costs

A weekend and an API bill

What V12 costs

A permanent product team

3. The decision rule, honestly cut

When is building actually right?

Build when the system itself is your moat. If your advantage is a proprietary data asset, a motion so unusual no product fits it, or GTM engineering you’d productize anyway — and you will fund the permanent team without starving it in year two — build. Teams like this exist; they know who they are, and a vendor’s guide should say so plainly.

Buy when your advantage is selling — understanding customers, finding the buyers who matter, building champions, closing accounts. Then every hour your org spends on identity resolution is an hour subtracted from the thing you’re actually best at, and the build is a hobby wearing an ROI slide.

The middle path most teams actually take — build “just the research part,” buy the rest — inherits both invoices: the integration seams become your edge cases. Pick a side of the rule.

If you land on buy, evaluate with a method, not a listicle: the five tests and their demo questions — run Narrative AI against them too; every send here is rep-initiated and every AI-suggested CRM change waits for a rep’s approval, which is test five passed by construction.

The question was never whether your team can ship V1. It’s whether you want to own V12 while the accounts keep moving.