You can build almost any GTM AI tool now. That is exactly why so many teams are stuck deciding whether they should.
This piece sets out the point of view Airspeed brought to our Build, Buy or Integrate conversation with Tom Andrews, who advises RevOps teams on AI with no product to sell. We work at Airspeed, so weigh our takes accordingly. The short version: define the blueprint, buy the engine, and build where you are different.
Want to run a specific workflow through the filter? The free Build, Buy or Integrate assessment scores it in about two minutes.
How has the build-versus-buy question changed?
AI makes building look easy, so more teams try. A working prototype now takes a week, not a quarter. But “can we build it” was never the real question. Companies have built their own CRMs, and most still buy one, because building, deploying, and maintaining a CRM rarely pays off. GTM AI follows the same logic.
The numbers back that up. MIT’s 2025 study of enterprise AI found about 95% of generative AI pilots showed no measurable P&L impact, and tools bought from specialized vendors succeeded at about twice the rate of internal builds (Fortune coverage of the MIT NANDA report). Gartner expects over 40% of agentic AI projects to be canceled by the end of 2027 (Gartner, June 2025). The failure point is rarely the model. It is everything around it.
What has to be in place before AI adds value?
Five things: CRM fields, metric definitions, sales stages, handoffs, and playbooks. Ask an AI assistant “How did marketing do last quarter?” without them, and you get a different answer every time, because the assistant has to guess what “pipeline,” “sourced,” and “quarter” mean.
The fix is not a better prompt. Define the process first, then let AI run the analysis on it.
Ownership of those definitions is a cross-functional job, not a tooling job. No platform can create alignment between sales, marketing, and customer success. It can only enforce an agreement that already exists.
Once the definitions exist, AI is good at keeping the foundation clean. It turns calls, emails, and other signals into structured CRM data, and it flags duplicates, missing fields, and stale records. That is also where AI should take admin off your team’s plate first: CRM updates, deal and implementation progress, hygiene checks, and first drafts of decks, spreadsheets, reports, and follow-ups. The time comes back to relationships, customer value, and trust.
Where does building your own AI win?
Homegrown AI wins at well-defined workflows with a clear template. Good examples:
- First-draft decks in your branded templates
- Account research briefs
- Recurring reports and spreadsheet updates
- Scoring logic specific to how your company wins
The teams that succeed here pick a narrow job, write the template down, and keep one owner on it.
Workflows that depend on full deal context are different. Follow-up emails and CRM updates after every call are easy to start and hard to make trustworthy at scale. The assistant has to know which opportunity the call belongs to, what was already in the CRM, and which fields it is allowed to touch. That is where building on top of an engine pays off.
Where is buying the better choice?
Buy where the hard part is not intelligence. Capturing every conversation, acting on it with full deal context, third-party data, forecasting, routing, and deliverability all fall here. If it has to run reliably on every interaction, involves compliance, or the data is the product, buy it and build on top.
The test for any purchase is whether it adapts to your business: your rules and definitions, your security and permissions, your playbooks, and your competitive positioning. A tool that makes you adopt its model of how you sell is not worth buying.
How do you decide for a specific workflow?
Run it through five questions:
| Question | Leans build if… | Leans buy if… |
|---|---|---|
| How important is owning it? | It encodes how you win | It is table stakes for every team |
| Is it worth the people, time, maintenance, and tokens? | The cost is small and bounded | It needs constant care after launch |
| Do you have a team to maintain it? | A named owner will stay on it | The builder is one person |
| Is the category moving faster than you can keep up? | It is stable | Vendors ship monthly |
| Can end users build on it, and does it act for them? | It is a one-off output | It must run proactively for everyone |
If the answers split, you are looking at the third option.
Is “integrate” a real option or a compromise?
It is the option most teams land on, and it is a real one. Define the blueprint yourself. Buy the engine that populates it. Insist on open access to its data. Then build a thin layer of logic on top, through MCP if needed.
Build your logic, do not build the harness.
That raises the ownership question. The context is yours: playbooks, CRM data, definitions. You are buying the engine that ingests it and applies it consistently, so it has to be portable if you leave. Put data access in the contract.
What do teams underestimate when they build?
The prompt is easy. The context is hard.
A prototype takes a week. A version reps trust takes months. For a mid-market team, our working budget is roughly $250K to $500K a year for one or two engineers plus RevOps time, before token costs. Four costs catch teams off guard:
- Access is not context. Connecting your tools to Claude or ChatGPT gives the assistant access. It reads a sample when asked, does not link systems, and depends on each person’s prompts.
- A paste is not automation. Dropping a transcript into an assistant and then updating Salesforce yourself is an extra step, not a step change. Real automation needs a trigger after each call, matching to the right opportunity, CRM permissions, and field rules: overwrite, append, merge, or leave alone.
- Playbooks go stale. A homegrown tool only knows your next steps and competitive positioning if someone loads them and updates them every time they change.
- Scoring is a product. Scoring every call, benchmarking by rep, team, and segment, linking behaviors to win rate, and flagging coaching moments takes a product, not a prompt.
The last cost arrives when the builder leaves, or when one team owns the tool. It becomes a ticket queue. If users cannot configure or build on it themselves, adoption stalls. Our longer piece, You could build AI sales infrastructure. But should you?, covers the maintenance math in detail.
What happens when every leader runs their own AI?
Without shared context, AI does not create alignment. It scales disagreement. Every leader gets a convincing answer from a different slice of data.
Here is the scenario we put to Tom. New business win rate drops. Five leaders ask AI why and come back with five different win rates and five explanations: price, lead quality, “it is flat,” security objections, and buyer delays.
Run the same question on one agreed win rate definition and every call, and a single cause shows up: security review starting too late. Deals that started security review before Stage 3 still won at the old rate.
The fix was one process change, not four:
- Add security requirements to the Stage 2 exit criteria.
- Reach out to the buyer’s security team early.
- Send a proactive security package.
- Track whether it happened on every call.
That is what “full context” means in practice: one customer across systems, a timeline, every interaction rather than a sample, shared definitions, traceable sources, and permissions.
How do you evaluate AI vendors now?
Every vendor claims AI, so test it on your own data. The question to ask: can you execute on our structure, accurately and automatically, so our people spend their time on relationships, customer value, and trust?
- POCs: expect meaningful results on your own data in weeks. A custom build during a POC is a fair test of adaptability, but ask whether it will ship in the core product.
- Data access: if a tool makes you export data to your own LLM to get answers, you are paying twice and spending your own LLM budget. Insist on full data access through APIs, warehouse sync, and MCP, and write it into the contract.
- Where it works: outputs should reach Slack, email, and the CRM, and the tool should act on users’ behalf rather than wait for a login.
- Contract length: favor shorter commitments while the technology moves this fast. A realistic middle ground is 12 months with an opt-out after a 90-day POC.
For a structured buyer’s checklist, see our guide to build vs buy AI sales tools.
Where does Airspeed fit?
Your context is yours. Airspeed ingests it, connects it, and applies it the same way every time: after every call, in Slack, in the CRM, or in your own Claude through MCP. Every call is matched to its deal, scored against your playbook, and measured with one definition across the whole pipeline. What your team builds then runs on trusted data.
If a RevOps leader does one thing next quarter, write down the blueprint: the fields, stages, metric definitions, and playbooks your AI will run on. Define the blueprint, buy the engine, build where you are different. AI should run your GTM logic, not invent it.
Score your next workflow with the Build, Buy or Integrate assessment, or book a demo to see the engine run on your own calls.
Frequently asked questions
Should a GTM team build or buy its AI?
Build where the work is a well-defined workflow with a clear template and the logic is specific to how you win, such as branded first-draft decks, account research briefs, or custom scoring. Buy where the hard part is not intelligence: capturing every conversation, acting on it with full deal context, third-party data, forecasting, routing, and deliverability. Most teams end up integrating: they buy the engine and build a thin layer of their own logic on top.
What does "integrate" mean as a third option?
You define the blueprint yourself (fields, stages, metric definitions, playbooks), buy the engine that populates it on every interaction, insist on open access to its data through APIs, warehouse sync, and MCP, and build your own logic on top. In short: build your logic, do not build the harness.
What does it cost to build GTM AI in-house?
A prototype takes about a week. A version reps trust takes months. For a mid-market team, our working budget is roughly $250K to $500K a year for one or two engineers plus RevOps time, before token costs. The prompt is easy. Loading and maintaining the context is the expensive part.
Why do GTM AI pilots stall?
MIT's 2025 research found about 95% of generative AI pilots showed no measurable P&L impact, and purchased tools succeeded at about twice the rate of internal builds. The common cause in GTM is missing foundations: undefined fields, metrics, stages, and playbooks. Without them, AI gives a different answer every time someone asks.
How do I decide whether to build or buy a specific workflow?
Run it through a filter. How important is owning it? Is it worth the people, time, maintenance, and token costs? Do you have a team to maintain it? Is the category moving faster than you can keep up? Can end users configure it themselves, and does it work on their behalf without being asked? Airspeed's free Build, Buy or Integrate assessment scores a workflow against these questions in about two minutes.
