Enterprise AI has exploded from $1.7B to $37B between 2023 and 2025, already 6% of the entire global SaaS market , despite being three years old.

Building has never been easier and it’s tempting too. When you can build exactly what you need, why wait on someone else's roadmap, why not own the thing outright? In 2025, 35% of teams already replaced at least one SaaS tool with a custom build, and 78% plan to build more in 2026.

In the last two years, the cost and time to build has dropped dramatically. AI-assisted development went mainstream, teams are getting innovative and shipping custom tools in days. Gartner has predicted by 2028, 75% of enterprise software engineers will use AI code assistants, up from less than 10% in early 2023.

‍When someone can build exactly what they need over a weekend, buying "good enough" solutions stops being good enough.

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.

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.

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?

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.

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.

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 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.

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.

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.

So where does that leave you? Build has a real case; Buy also has a real case. If you've been nodding along to both sides, that's the right read. You don’t need to be choosing one or the other.

‍78% of organizations that successfully deployed AI worked with external partners for at least part of it. The hybrid model now accounts for the majority of enterprise AI spend: buying the foundation, building the intelligence layer on top.

The key question isn't build or buy. It's which layer you're talking about, because the answer changes completely depending on where in the stack you're deciding. That's the hybrid playbook.

Nobody building on Shopify debates whether they're "really" building a business. They are, because they're making real product decisions, growth decisions, campaign decisions. The foundation is bought and the value is built on top.

The same logic applies here. Some things you buy: the models, third-party signal data, infrastructure, compliance controls. Some things you build: the plays, the priorities, the calls about who to go after and when. The pattern that's emerged across the data: buy for speed and reliability at the base, build for differentiation where you actually compete.

AI has reduced the cost of creating software but it hasn't eliminated the cost of owning it. Once you've built something, you're in for model updates, governance, security risk, and components that can quietly break, then scale. Before committing to building any layer, be honest about what sustaining it actually requires.

What's different now is that for the first time, almost anyone can build, which makes the decision much harder.

UserGems' CEO and co-founder, Christian Kletzl, came up as a product manager, and the most important skill he learned was knowing how to say no, because every yes costs you something else. That discipline matters more now than it ever has, because the barrier to building has dropped so far that the thing standing between a good decision and a bad one is often just the willingness to ask whether you should.

The teams should be getting honest about what their job actually is. RevOps isn't just ops. It's revenue.
Everything you build, buy, or maintain should be in service of revenue, not infrastructure for its own sake. When a build decision pulls your best people away from generating or protecting revenue and into tool maintenance, that's the wrong layer getting your attention.

There's also something worth saying that doesn't get said enough: nobody has fully figured this out yet. The question of where AI actually creates surprise value (not incremental efficiency, but genuine capability you didn't have before) is still being answered in real time. The honest move is to stay curious, stay skeptical of hype in both directions, and keep asking whether the thing you're building or buying is moving the number that matters.

Buy what you need, build what only you can build, and know when to say no.

We'd be hypocrites not to answer that ourselves, so here's how we actually apply it at UserGems.