Every GTM systems team faces this decision several times a year: the business needs a capability - routing, enrichment, forecasting, quoting, attribution - and someone has to decide whether to buy a tool or build it on the platform you already own. Both directions have a graveyard. Orgs that buy everything end up with 40 tools, overlapping bills, and integration debt nobody can map. Orgs that build everything end up with a bespoke system that only one admin understands, held together by Flows nobody dares touch.
The False Comparison That Starts Most Bad Decisions
The naive math compares the vendor's annual price against the cost of building the first version. That comparison is wrong on both sides. The build side is not the build cost - it is the ownership cost: maintenance, documentation, enhancement requests, testing on every Salesforce release, and the bus factor of the person who built it. A reasonable rule of thumb is that year-one build cost is a third or less of three-year ownership cost.
The buy side is not the license fee either - it is license plus implementation, plus the integration you now maintain, plus admin time in yet another tool, plus the switching cost you will pay when the vendor gets acquired, sunsets the feature, or triples the renewal. Neither number on the invoice is the real number.
The Framework: Three Questions in Order
1. Is this capability differentiating or commodity? If the capability works the same way at every company - email deliverability, calendar scheduling, e-signature, data enrichment - buy it. Vendors amortize their R&D across thousands of customers and will out-execute your internal version forever. Build only where your process is genuinely different in a way that creates advantage: your unique routing logic, your pricing model, your customer lifecycle. The test: would copying a competitor's version of this hurt us? If no, it is commodity. Buy.
2. How close is the need to our system of record? Capabilities that are mostly reads and writes against your CRM data - scoring, routing, territory logic, deal desk workflows - lean build, because you already own the platform, the data model, and the admin skills, and every vendor solving these problems is essentially selling you a UI on top of your own data. Capabilities that require external data or infrastructure you do not have - intent data, parallel dialers, conversation intelligence - lean buy, because the vendor's moat is the part you cannot replicate.
3. Can we survive this being mediocre for a year? Internal builds start mediocre and improve if - and only if - they get sustained investment. If the capability is urgent and must work on day one (compliance, billing, anything customer-facing), buy the proven tool. If you can iterate quietly (an internal dashboard, a scoring model, an ops workflow), building is viable.
The Decision in One Table
BUY BUILD
Capability type Commodity Differentiating
Data location Vendor's data/infra Your CRM data
Urgency Must work day one Can iterate
Team Admin-heavy Dev capacity exists
Change rate Stable requirements Requirements evolve
with your processThe Two Failure Modes to Design Against
The shadow build. You bought the tool, but ops does not trust it, so someone rebuilds half of it in spreadsheets and Flows alongside. Now you are paying for both, and the two disagree. If you buy, commit: migrate the process fully and decommission the workaround, or the tool becomes shelfware with a renewal date.
The abandoned build. The internal tool shipped, its builder got promoted or left, and now it is load-bearing legacy nobody owns. Before any build starts, the question is not "can we build it?" - you almost always can - it is "who maintains this in year three, and is that in their job description?" No named owner, no build.
The Hybrid Most Teams Should Run
In practice the answer is usually layered: buy the engine, build the logic. Buy the enrichment provider, build your own scoring on top of its data. Buy the routing tool if your logic outgrows Flows, but keep the routing rules expressed in your own configuration, not scattered through the vendor UI - so switching vendors later is a migration, not a rebuild. The principle underneath: own the logic that encodes how your business works, rent the infrastructure that delivers it. Vendors should be replaceable; your operating model should not be trapped inside any of them.