Build or Buy Your GTM Stack: Four Questions That Settle It

Nobody should build their own SMTP infrastructure. Almost everybody should build their own definition of a qualified account. Build-versus-buy arguments go wrong because they get settled by temperament, engineers preferring to build and finance preferring to buy, rather than layer by layer against four questions.

Question one: is this a differentiator or a commodity?

The test is not "is it important". Email sending is critical and wholly commoditised. The test is whether doing it differently from competitors produces an advantage. Sending an email is a commodity; deciding which account gets it, at what moment, on what behaviour, is not. Storing a deal record is a commodity; defining when a deal becomes real is the argument your revenue process turns on.

The heuristic: if two competent companies in your category would reach the same answer, buy it. If the answer is contested inside your own company, that contested thing is yours, and encoding it in a vendor's schema adopts their opinion by accident.

Question two: how fast does the vendor category move?

In a fast category, a vendor's R&D outruns anything you could maintain. Ad platforms ship bidding changes quarterly, enrichment providers rebuild pipelines constantly, deliverability vendors chase mailbox provider policy changes that arrive with weeks of notice.

In a slow category the advantage decays. A routing rule engine is the same problem it was a decade ago, and a view over your own warehouse is not improved by a vendor's roadmap. The check: read the vendor's changelog for the last twelve months. If most entries are UI tweaks and new integrations, the category is slow and you are renting a wrapper.

Question three: what does it cost to leave?

Exit cost is the number nobody prices at purchase, and it has three parts. Data portability: can you get history out in usable shape, or does the export return current state with the event history trapped inside? Logic portability: how much business logic lives in the vendor's rule builder and nowhere else? Identity portability: if the vendor assigns its own IDs and your systems key off them, unwinding that is a migration.

A ten-minute check: pick your three most expensive tools and ask whoever runs each what you lose permanently if you cancel tomorrow, and how long replacing it takes. An answer longer than a quarter, for a tool you consider tactical, is a lock-in problem you have not been pricing.

Question four: who fixes it at 3am?

For a bought tool the honest answer is nobody, and the SLA does not mean what you think: when an enrichment provider degrades quietly, you find out from a rep complaining about bad data three weeks later. For a built tool the answer must be a named person with a runbook, and if you cannot name them you should not build it. Build decisions fail here: not at the build, but eighteen months later when the author has left and nobody understands the retry logic.

Where buying wins almost every time

Email sending infrastructure. IP reputation, feedback loops with mailbox providers, bounce classification, and compliance with bulk sender requirements that changed twice in two years. Postmark, SendGrid, Amazon SES: pick one.

The CRM. A system of record with permissions, audit history and an ecosystem your next sales hire knows. Building it is a decade of work to reach a worse Salesforce.

Data enrichment. The value is the collection operation, not the software. Buy two providers and use the second as a coverage check on the first.

Ad platforms and the warehouse. Do not build a bidding layer on top of the platforms either: their optimisation has more data than yours ever will. And managed BigQuery, Snowflake or Postgres is cheaper than your time.

Where building wins more often than people expect

The signal layer. What counts as a buying signal, how events are named, how a visitor resolves to an account, what consent state is attached. Every CDP and analytics vendor offers you their schema, and adopting it makes your definition of a buyer's journey a vendor's opinion. You find this out the first time you ask a question their model did not anticipate. A first-party signal ledger is a few tables and a capture endpoint, and it survives every migration.

Routing logic. Who gets which account, under what conditions, with what fallbacks. This encodes territory politics, capacity and specialisation rules specific to your team, and they change quarterly. In a vendor's rule builder it becomes forty nested conditions nobody dares touch. As a file in version control it is reviewable and testable.

Internal reporting views. Once the warehouse holds the data, a view is a SQL query. Buying a BI tool to render it is reasonable; buying one that re-implements your metric definitions in its own semantic layer gives you two sources of truth.

Anything that encodes your own definitions. Scoring, lifecycle stages, what "qualified" means, what churn risk looks like. These are arguments your company has to have, and outsourcing them to vendor defaults means the argument never happens and the defaults win.

The costs neither side admits

Buying carries integration debt: connections grow faster than tools, twelve tools is sixty-six possible pairs, and even the ten you build break independently. It also carries seat-based pricing, which scales with headcount rather than value, gets more expensive exactly when you hire, and quietly rewards under-licensing and shared logins. Check renewal quotes for the model, not just the number.

Building carries a maintenance tail longer than the build. A weekend script becomes a dependency, then an undocumented one, then a load-bearing one. If you cannot fund roughly a fifth of the build cost per year in maintenance, buy instead. Building also risks the wrong abstraction early: encoding a process you have run three times produces infrastructure that fits a sample size of three.

The middle path: own the data, rent the interface

The most durable pattern is neither: own the layer underneath and rent what sits on top. Your events land in your warehouse, in your schema, with your definitions, and that is not negotiable. Above it, tools are interchangeable. Reverse-ETL syncs segments into the ad platforms and the CRM, a BI tool renders views defined in your own dbt models, a sequencer sends the email but the audience comes from your tables. That is what makes switching a vendor a two-week project rather than a two-quarter one, and why the marketing-as-code pattern applies: definitions live in a repository, under review, and the tools read them.

Where it fails is real time. If a decision must be made in under a second, in the browser or during a call, a warehouse round trip is too slow and you either accept a vendor's edge infrastructure or build a caching layer, a real engineering project. Most B2B routing tolerates five minutes, and teams routinely specify sub-second latency for things a human acts on the next morning.

The other limit is staffing. The pattern needs someone who can maintain a warehouse and a transformation layer. At a company with no data function it is aspirational, and a more integrated suite is right until that capability exists. A scoped build with a dated handover is one way there without a hire.

Frequently asked questions

When should a company build its own GTM tooling instead of buying?

Build when the thing encodes a definition specific to your business, when the vendor category moves slowly, when the exit cost of the bought alternative is high, and when you can name who will maintain it. In practice: the signal layer, routing logic, metric definitions and internal reporting views. Buy email sending infrastructure, the CRM, data enrichment, ad platforms and the warehouse.

What are the hidden costs of buying GTM software?

Integration debt, which grows faster than the tool count because each connection breaks independently. Seat-based pricing, which scales with headcount rather than value and costs more exactly when you hire. And exit cost: history trapped in an export that returns only current state, logic living in a vendor's rule builder, other systems keyed off the vendor's identifiers.

What does "own the data, rent the interface" mean?

Your events, definitions and history live in your own warehouse under your own schema, while the tools acting on that data stay interchangeable: reverse-ETL pushes segments into ad platforms and the CRM, BI renders views from your own transformation layer, a sequencer sends email to an audience built from your tables. Switching a vendor then takes two weeks rather than two quarters, though it does require someone able to maintain a warehouse.

How do I know if a vendor category is worth paying for?

Read the vendor's changelog for the past twelve months. If most entries are substantive, keeping pace with platform changes, pipeline rebuilds or policy shifts you could not track yourself, the subscription buys real R&D. If most are interface tweaks and new integrations, you are renting a wrapper.