Build vs Buy: What 67 GTM Teams Told Us About Building It Themselves
- Buyer's Guide
- 9 min
- October 19, 2026
Executive Summary
The build vs buy question has changed for go-to-market teams. AI made building cheap, so almost every team can build its own CRM data tooling. We hear it on most of our calls. So we went back to them and reviewed 193 calls across 67 companies where building in-house came up.
Most teams build something, and they should. The ones that got value from AI built the intelligence their business is judged on and bought the data layer underneath it. This post covers the five kinds of build we saw, where each one breaks, and five questions to answer before you decide.
Why Build vs Buy is on Every GTM Team Agenda
A tool that once took a quarter to build can now take an afternoon. Most revenue teams have at least one engineer or RevOps lead who has already proved it. So when a CRM data problem comes up, “We’ll build it” is a reasonable first answer.
We noticed a consistent pattern. Teams that got value from AI drew the build or buy line in the same place. They built what makes their business different: ICP definitions, deal strategy, win-loss and churn models, agents, and the checks on AI output. They bought what has to be right every day: capturing every email and meeting, matching each one to the right contact, account and opportunity, and keeping the full history in their own CRM.
Kyle Norton, former CRO at Owner.com, puts the same split bluntly:
“Buy the systems where uptime, reliability, compliance, and scale matter more than uniqueness.”
Get our latest insights into your inbox
The 5 Kinds of Build and Where Each One Breaks
“We’ll build it” covers five different projects. Each starts for a different reason and fails in a different place, so it helps to know which one you are running before you weigh build or buy. Counts are companies in our sample, and some ran more than one.
1. The Stitched Stack (16 companies)
Every team buys its own tool, and each tool writes to Salesforce. Sequencing, call recording and the CS platform each get an integration. Nobody approves a data pipeline, but three integrations signed months apart add up to one.
It breaks because each tool writes its own version of the same event. One logs a meeting as a task, another logs it as an event, and the records never reconcile. Much of the history also sits in each vendor’s own objects, so it leaves when the contract does. As Abhijeet Vijayvergiya, Nektar’s co-founder and CEO, puts it:
“It’s on rent, it’s not permanent.”
2. The Warehouse Cleanup (21 companies)
This was the largest group. The thinking is simple: “We have a warehouse and data engineers. We’ll fix it downstream.” These teams usually do have the skills.
It breaks because you cannot clean data that was never captured, or match a meeting to a deal after the context is gone. Teams end up parsing, deduping and pushing records back into the CRM. Some of the most expensive people in the company spend their time on cleanup.
3. The In-house AI Team (8 companies)
The company has a real AI team, an MCP stack and a warehouse, so buying anything that touches AI looks redundant.
It breaks because the AI team is rarely pointed at go-to-market. A GTM leader at a fintech infrastructure company told us their central AI team is “mostly there to make sure [we have] access to the technology and it’s governed.” GTM requests wait in line behind everyone else’s.
4. The “use what we already pay for” Build (10 companies)
An executive who already pays for an LLM, a call recorder and a CRM asks why the company should pay again. The champion has no number ready.
It breaks because the team spends a few cycles assembling the answer from existing tools. Win-loss analysis is the usual example: transcripts, CRM exports and raw email dropped into an LLM by hand, with a token bill nobody tracks. The gaps show up a quarter later.
5. The build on top (11 companies)
Same engineers, same ambition, different line. These teams build the agents, models and dashboards, and buy the capture and matching underneath. Many teams from the first four groups end up here after a quarter or two.
What they built on top was specific to each business. A fintech company built a signal that flags when nobody has spoken to a customer’s CFO, its earliest churn warning. A cybersecurity company built a white-space agent that maps which product to sell into which account. A contract software company built a model that tests whether sales engineer involvement in a trial predicts a close. None of these are products anyone sells. Each runs on matched activity data the company owns.
Why An Internal Build Looks Free
An internal build is paid for by people already on payroll. On a budget sheet it costs nothing, so anything you buy shows up as new spend against a zero.
A GTM operations leader at a compliance software company described this exactly. His team had spent several quarters building its own activity reporting “in sweat equity,” with “no dollars tied to it outside of the timing and effort.” His biggest obstacle to buying was explaining new spend against a build that appeared to cost nothing.
The build also got harder to leave every month. More reports, dashboards and habits depended on it, so switching meant restating history and re-enabling the field. Meanwhile the build had stopped where the work got hard. Partner activity, close to a third of that company’s revenue, had never been tracked.
The Cost Nobody Adds Up
In a build vs buy decision, the model is the inexpensive part. The expense is in making customer data trustworthy enough for a model to act on, then keeping it that way. Teams tend to hit four hard problems, usually after the budget is approved:
- Identity resolution. A buyer joins from a personal phone under a different name. Rule-based matching guesses, and a wrong guess raises no error.
- Association. A transcript records what was said, but not which opportunity it belongs to when two are open on one account.
- History. A model with no history has no baseline, and restating the past is rarely scoped at the start.
- Compute. Tokens, API calls and storage grow with every rep and every meeting, and in-house the company carries all of it.
Then someone has to own it. A RevOps leader at a fraud-prevention software company gave the warning most teams learn late: “Be careful what you build because you might have to maintain it.” One internal build had turned a teammate’s whole role into maintenance.
Engineering capacity is rarely the real constraint either. A fintech company told us it could put “up to 10 engineers” on GTM projects. It bought the data layer anyway and pointed those engineers at what sits on top.
Build or Buy: How AI Transformation Leaders Decide
We asked the same question of AI transformation leaders on The Revenue Lounge, Nektar’s podcast. Three of them, at three different companies, landed in nearly the same place.
Pino Soro, Chief Business Transformation Officer at QuickBase, says pilots are designed to succeed: “You take your best people, you take a really clean use case.” Scale is where they fail. His team now buys what the market does better and saves data engineering for what is unique to QuickBase. Everything they build gets a named business owner and a named technical owner.
Amrutha Suresh, who leads GTM AI and innovation at Asana, is direct about the line: “I probably am never going to build a CRM.” Her team builds the semantic layer, the context layer and multi-agent orchestration. For gray-zone cases, she models the economics first: reps, tokens and orchestration cost against the vendor’s bill. She also counts maintenance, which she calls “an invisible sort of a hidden cost.”
Tim Seamans, VP of AI and Business Transformation at Mimecast, expects every vendor to ship generative AI, which makes adopting the same tools a short-lived advantage. Mimecast builds for proprietary advantage and buys the rest. It also ran the experiment in order. An internal GenAI app produced thin insights because emails were not matched to the right Salesforce records. Mimecast bought the data layer underneath, and the same app started producing useful insights. Read the Mimecast story.
All three build what encodes how their business works, buy what someone else runs better at scale, and put a named owner on everything they build.
Build or Buy? 5 Questions to Answer First
Take these into the room before the decision is made. A question you cannot answer yet shows you where the risk is.
- Which parts of this are your judgment, and which just have to work every day? Build where your definitions and decisions are the product. Buy where being reliable matters more than being different.
- What will your team build on top, and what does it need underneath? Name the agents, models or dashboards. For each, list the data it needs: which emails and meetings, matched to which records, going back how far.
- Who keeps it running a year from now? Name a business owner and a technical owner, and decide what happens when the builder moves on.
- If you switched off a tool tomorrow, which records would stay? Check which activity history sits in your own Salesforce objects and warehouse, and which sits in a vendor’s objects.
- What has the build already cost, and what is it stopping the team from doing next? Count people, upkeep, tokens, API calls, storage and the channels the build does not cover.
Enjoyed our content? Follow Nektar on LinkedIn
