Speed to value matters 

‍

When a suitable solution exists, buying reduces time-to-market by 70% or more. (For GTM and RevOps teams running on quarterly targets, that's the difference between running a campaign this quarter and scoping one for next year.

‍

Even in areas where in-house builds used to be the default like knowledge management and workflow automation, .enterprises are migrating toward packaged solutions because the speed and reliability have caught up faster than most teams expected. For most GTM use cases, a long custom build cycle simply isn't competitive anymore.

‍

The real cost of building is almost always underestimated

‍

Most custom software projects run over budget, but custom AI builds can cost significantly more. 85% of organizations misestimate AI project costs by more than 10%, and a significant chunk miss by over 50%. The usual culprits: data preparation taking longer than expected, integration complexity, and infrastructure costs that scale faster than anyone projected. (

‍

It's no surprise that the stats show it doesn't get cheaper once you ship. Retraining adds 15-30% ongoing overhead on top of the original build, so that "one-time build cost" is rarely one-time.

‍

On average, a custom build takes 33 months to pay for itself, and that's assuming nothing breaks, nobody leaves, and a vendor doesn't ship the same thing cheaper while you're still building it.

‍

Lightbulb icon: This doesn't mean don't build.  It means be honest about what you're actually signing up for and ask whether building that particular layer is really your job (and whether you can really maintain it). 

‍

‍

Headcount problems 

Someone has to maintain what gets built. Usually that job lands on someone who was hired to sell or run campaigns, not maintain infrastructure. A production AI system needs constant attention: retraining models, fixing broken parts and figuring out why something stopped working. All of this is basically a second job.

‍

Most RevOps and GTM teams don't have spare engineers sitting around for this. Just because someone is good with Claude doesn't mean they should be the maintainer of a system they never agreed to own. If you're building, ask yourself: if this broke tomorrow, who fixes it? What stops getting done while they do?

‍

‍

Vendors carry the risk you'd otherwise own

‍

Most GTM teams handle contact data, CRM records, and intent signals, where compliance is a liability.

‍Getting SOC 2 Type II certified alone takes 6 to 12 months, before you even factor in GDPR, CCPA, and the EU AI Act, which entered enforcement in 2025. Initial compliance setup adds 15-20% to total project costs, and ongoing compliance costs exceed upfront expenses by 25-30% due to continuous monitoring requirements.

‍

Reputable vendors have already absorbed that cost. Building internally means owning it yourself: the audits, the documentation, the annual renewals, and the engineering time it pulls away from everything else.

‍

Compliance failures are a real risk too. In June 2026, a breach at Klue, exposed keys to customers' cloud services across roughly 200 customers, including security vendors like Jamf, HackerOne and LastPass.  The point isn't that vendors don't get breached, they do. It's that a reputable vendor has a dedicated security team, an incident response plan, and a legal obligation to disclose fast. 

‍

A vibe-coded internal tool has none of those, and the IT team that's supposed to secure it is already stretched across a dozen other priorities.

‍

Lightbulb icon: The risk still exists, buying just puts it in hands that are paid to manage it professionally.

‍

The “just build it in Claude” trap for outbound

‍

Ask Claude to analyze your calls for the day, prep an account brief, or summarize a prospect's recent news, it works well. That's exactly where the trap is: if Claude can do this, surely you can run your whole outbound motion through it, right?

‍

People aren't wrong to want to build in Claude, but perhaps they need to question more about what it's for. It's great for using it to prototype, to pressure-test an idea, to figure out what you actually need before committing. Where it breaks down is when the prototype ends up becoming the product.

‍

Claude's been life changing for those one-off, time consuming tasks where you hand it everything it needs and it works its magic. But outbound is different as it's a system that runs constantly. You need to monitor your internal sales and customer pipeline while watching thousands of external accounts every day, catch the moment something changes, and act before your competitor does. That's not really something you can quickly prompt your way into.

‍

Another tricky part is each Claude session starts from zero unless you've engineered it not to. For most teams building quickly in Claude, there's no memory, history, or paper trail. That's fine for a one-off task but for an always-on system running at scale, when something goes wrong, you need to investigate when it started, why it happened, and how far it spread. That infrastructure doesn't come for free.

‍

“Looks right” is a verdict you can only render when you already know the right answer. For ten documents your team has read closely, it works. For hundreds you haven’t, it isn’t verification, it’s a guess that scales. - Eric Hawkins, CTO (Hawkins, 2026)

‍

None of this makes building impossible. You can engineer around these limits, memory, data pipelines, security, ongoing maintenance, if you have the technical resources to build them. But the version of “build” that actually holds up in production, one with monitoring, error handling, and someone accountable when it breaks, looks a lot like the product you were trying to build your way around.

‍

Most GTM and RevOps teams don't have spare engineering bandwidth sitting around to build that version, which makes the real question less about whether you can and more about whether a homegrown system is where your business gets the highest ROI. Is it actually your moat? So here's where Team Build actually has a point.

If your data is the moat 

‍

This is usually the first place GTM teams land when they argue for building: their data. If you're sitting on signals nobody else has, and no vendor can get their hands on them, a model trained on that data will beat anything off the shelf.

‍

Years of pipeline history, how accounts actually engage, why deals are won and lost, and how your reps behave are exactly the kind of asset GTM teams are sitting on, and exactly the kind no vendor can get their hands on. Unless, of course, a competitor could just go buy the same insight somewhere else.

‍

Most teams are sitting on this data and never actually put it to work. That's the real missed opportunity, but only if you build at the right layer.

‍

ClickUp evaluated a wave of AI vendors for its GTM operations and didn't find one with the right fit. So they left their Salesforce, Zendesk, and Snowflake stack alone (that data layer stayed bought) and built six AI tools on top of it instead, tools that ran on their own customer and support data. It automated hundreds of hours of weekly work, saved hundreds of thousands in headcount costs, and cut $200K a year in automation software.

‍

Harmonic ran into the same decision from a different angle. A $20K/year third-party tool couldn't move fast enough, so instead of rebuilding their own Salesforce and Gong data underneath it, they rebuilt the tool itself on top of that data. That one rebuild turned into 33 internal apps, still running on the same Salesforce, Gong, Slack, and internal API connections, with audit logs and role-based access built in. (Retool, 2026)

‍

Neither team touched their actual data or the systems holding it. What they built was the layer that used it — the workflows and automations that turned pipeline and support history into something nobody could buy off the shelf. That's the difference: the data stayed bought, the leverage got built.

‍

The data can absolutely be your moat. But rebuilding the infrastructure that stores, cleans, and maintains it isn't where your time pays off. The campaigns and plays you run on top of it are. Owning the asset and owning the infrastructure underneath it are two different decisions. Mix them up, and six months later you're still building the foundation, when all you needed was a better campaign.

‍

The tool should do what you need, not the other way around

‍

The core frustration with SaaS is that products make you work their way. When your workflows are genuinely unique, buying a platform can mean bending your whole motion to fit someone else's assumptions. When it’s not a good fit, new reps take longer to ramp, workarounds turn permanent, some plays you just can't run, because the tool was never built for how you actually sell.

‍

Digital Applied costed this out and they came to the conclusion that over three years, building it yourself costs about 5% more than renting the SaaS version, $88,600 versus $84,400. A hybrid setup beats both, at $79,600. More on that later.

‍ 

This is where building earns its place: the workflow layer, the part that actually reflects how your team prioritizes, works, and closes.

‍

Vendor lock-in: The case for building your way out

‍

One of the key arguments is that vendors are making it harder to leave. Forrester puts it plainly: "your next major software decision is a bet on a single vendor's security posture, pricing model, and innovation capacity for the next decade".  Switching typically costs twice your initial investment and if you do, only 42% of executives in 2025 who tried switching said it actually went smoothly.

‍

The lock-in tax shows up in the numbers. HubSpot raised prices on its Professional and Enterprise tiers 19-25% in 2024. Webflow's CMS plan jumped 43.75%, from $16 to $23 a month, when it raised prices across the board in 2022.

‍

Light bulb icon: Building can be the way out of vendor lock-in but whether it actually holds up depends on one thing: can you sustain what you build once you're the one keeping it alive?

‍

POV from the people

‍

(insert visual) 

‍

Eric Hawkins, CTO of a private markets AI company, offers three conditions that all have to be true before a build decision makes sense. The scope has to be contained. The logic has to be uniquely yours, encoding judgment that reflects how your firm actually works, not generic best practice. And the maintenance burden has to be one your team can realistically sustain long-term. When all three are true, building creates a durable advantage. When any one is missing, you're starting a maintenance treadmill you'll regret in 18 months. (Hawkins, 2026)

‍

(lightbulb icon) Our thoughts: The build conversation usually focuses on launch. The harder question is what happens six months later when the person who built it has a new priority, a new role, or a new job.

‍