Every GTM technology leader runs the same meeting eventually. Sales wants a tool they saw at a conference. The vendor's ROI deck is beautiful. Engineering points out you already own three platforms that do 70% of it. Finance wants to know why the stack budget keeps growing while half the licensed capabilities sit unused.

"Buy vs. build" gets framed as an engineering question, but in revenue technology it's really a portfolio question: every dollar and every hour of admin capacity you commit to one capability is a dollar and an hour you can't commit to another. After sixteen years running GTM stacks — CRM, marketing automation, service, web analytics, and the data platforms underneath them — here's the framework I actually use, and three real decisions that show it working.

The Framework

The decision tree hasn't changed much, even as AI has made building feel dramatically cheaper:

Buy when the capability is commodity

Identity, email deliverability, consent management, core CRM objects. These are solved problems where vendors amortize compliance, security, and edge cases across thousands of customers. Your custom version will be worse, and nobody will thank you for it.

Build when the capability is your differentiation

The way your funnel attributes revenue, the way your data joins sales activity to marketing spend, the way your team's workflow actually runs. Vendors sell the average of their customer base; your differentiation is precisely the part the average doesn't cover.

Compose the hybrid

The most durable pattern is buying the foundation and building the thin differentiating layer on top — native platform features plus your own glue, rather than a new tool per capability.

And its mirror image deserves equal billing: "Not Purchased Here" syndrome — buying a dedicated tool for every capability because procurement is easier than prioritization. That's how stacks grow shelfware.

Decision 1: Sales engagement — build it inside the platform you already own

The ask was a familiar one: dedicated sales-engagement tooling, the Outreach/Salesloft category. Sequenced touches, activity capture, cadence analytics. The category is real and those products are good at it.

But we already owned a Salesforce estate with most of the raw ingredients: activity objects, flows, email integration, and reporting infrastructure. The gap wasn't capability — it was assembly. So instead of adding a tool (new contract, new integration surface, new admin burden, new place for data to be wrong), we delivered sales-engagement capability natively inside Sales Cloud: sequences modeled on platform objects, activity capture through the existing email integration, and cadence reporting in the analytics layer the team already used.

What made this a build decision wasn't pride — it was that the "build" was small and the "buy" was double-spend. We were already paying for the platform; the differentiation was a thin layer of configuration and glue, not a product.

The deferred half matters too: conversation intelligence (the Gong/Chorus category) didn't make the cut — not because it lacks value, but because the capability we could operationalize now beat the capability we'd aspire to later.

Decision 2: Portfolio rationalization — sometimes the answer is neither

The hardest buy-vs-build decisions aren't binary; they're "should this capability exist in our stack at all?"

Reviewing a marketing automation estate, we found licensed modules that had never been operationalized — capabilities bought in an optimistic moment that the team never had the bandwidth to run. The rationalization was unglamorous: mark what's genuinely used, cut or stop renewing what isn't, and concentrate the freed budget and attention on the modules that carry real workflows (nurture journeys stayed; aspirational add-ons went).

The discipline is in saying no to capabilities we can't operationalize. A capability isn't an asset until someone runs it — until then it's a liability with an invoice. This is also the honest answer to most vendor ROI decks: the tool may genuinely do what it claims, and it still loses to the question "who on my team operates this on week 40?"

Decision 3: Attribution — build, because the answer wasn't for sale

Marketing attribution was the clearest build decision of the three, because what we needed didn't exist as a product: our ad platforms, GA4/GTM behavioral data, and CRM records joined on our own customer lifecycle, under our own governance.

The build: land ad platform, GA4/GTM, and CRM data into a lakehouse — S3 and Lake Formation for storage and governance, Redshift for the warehouse, Lambda and Glue for the pipelines. On top of that foundation, roughly 90% of marketing spend became attributable across the customer lifecycle.

Note what was bought and what was built. The storage, governance, warehouse, and orchestration are all bought commodity (cloud services). The built part is the joins, the lifecycle model, and the governance decisions — the layer that encodes how this business measures itself. That's the composable pattern from the framework: nobody sells your attribution model, but everybody sells the infrastructure to run it on.

It also pays forward: AI on governed data is only as good as the governance. The same lakehouse that answers attribution questions is the substrate for natural-language analytics — a capability that would have been impossible to buy credibly and irresponsible to build without the foundation.

Run the Numbers Yourself

This site's sandbox has two interactive tools I use to structure these conversations:

• The ROI calculator compares build and buy cost curves over time — plug in your own numbers; the state lives in the URL, so you can send your scenario to whoever you're trying to convince.
• The decision matrix does weighted scoring across factors like differentiation, compliance burden, and operational capacity.

Neither tool will make the decision for you. What they will do is force the disagreement into the open: when two stakeholders produce different answers, the interesting conversation is about which weights they disagree on.

What Changed in the AI Era, and What Didn't

AI genuinely moved the line. Builds that were a quarter of engineering time are now weeks; the sales-engagement layer above would have been a harder call five years ago. But three things haven't moved:

1. Operational complexity survives the build. AI writes the first version; it doesn't run week 40. Every build decision is a hire-or-allocate decision in disguise.
2. Vendors got AI too. The same force making building cheaper is making bought products more capable and more configurable. The bar for "we can do better ourselves" went up, not down.
3. Governance is the new moat. As more of the stack becomes AI-assisted, the differentiated asset is clean, governed, joined data — which is a build, and always was.

Buy the commodity. Build the differentiation. Rationalize what you can't operationalize. And be suspicious of any framework — including this one — that always produces the answer its author wanted.