The guide to building your GTM Data Foundations

What You'll Find Inside

This guide is for RevOps, data and GTM leaders who are seriously considering building their own TAM and contacts dataset for local and for the eng and data leaders who'd have to own it. It's built from interviews with every engineer on our data team plus our CTO, and from conversations with hundreds of orgs selling into local businesses over the past year.

‍

We sell this data. We're still going to teach you how to build it. Our CTO's position is that anyone can do what we do with enough money and resources. But where orgs get it wrong is that they underestimate the true scope and complexity of the build. It’s so much more than just “building a scraper”.This guide shows you the outlines of the whole system so you can understand the full scope of a data foundations buildout.

‍

The core insight: acquiring the data is the part everyone scopes, and it's about 30% of what this costs. The other 70% is entity resolution, refresh, verification, evaluation and the people who run it forever. Teams don't fail at building GTM data foundations because scraping is hard. They fail because they budgeted for the scrape.

‍

This guide gives you the architecture, the failure modes, the evaluation criteria and a working cost model, so you can scope the build honestly — and decide which parts are worth building at all.

Key Stats That Matter
Stat
What it means
Section
Acquisition = 30% of tech spend
The scrapers and third-party sources are the cheap part. The bulk of the TCO goes to storing, manipulating and verifying
60%+ of local businesses have no unique domain
In enterprise, same domain = same company. In local, the cheat code doesn't exist
5 sources, 100% coverage, 20–30% of accounts still missed
A public company bought five sources that covered every business in their TAM. Their pipeline still lost a quarter of every market in the join
22–25% of businesses close in year one
This sets the baseline rate at which your TAM goes stale. Salon and wellness lists run 20–30% dead in twelve months
95% precision, or reps stop trusting it
The benchmark to hit on TAM and contacts. Below it, your team reverts to manual research
Three Zones, Three Defaults
Most teams argue about "build vs. buy" as one decision. It isn't. Break the project into components and each one answers differently:

Could you swap yours for a competitor’swithout anyone noticing?

‍

Buy →

‍

Let the vendor amortise maintenanceacross every customer they have.

‍

‍Start here →

Is this just how your org runs?

‍

Configure →

‍

On the platform you bought. Yours, but assembled, not constructed.

‍

‍Start here →

Would being better at this than yourcompetitor show up in win rates?

‍

Own →

‍

This is institutional knowledge, and your edge.

‍

Start here →

Section 2 works this capability by capability — including the harder question of where a data foundation sits,since it looks like commodity infrastructure and behaves like neither.

If you're in GTM Strategy / Leadership
1.2
/

Should You Build Yourself? - the three-zone test for what to own vs. buy

1.1
/

The Imperative — why the status quo isn’t working and the strategic implications

1.7
/

The True Cost — what the build and the run actually cost, with a working model

If you're in RevOps / Data Ops
1.3
/

Data Sources — the source landscape, and the marginal-lift trap

1.6
/

Evaluation Criteria — precision and recall per field, golden sets, running a fair pilot

1.5
/

Maintaining Pipelines — refresh cadence as an economic decision, and who owns dataset health

If you're an Engineering / Data leader
1.4
/

Entity Resolution — surface then evaluate, match at location level, roll up

1.5
/

Drift — how you catch divergence before your reps do

If you need to make a case internally
1.7
/

BUILD and RUN — the line-item model, with benchmarks and vendor pricing calculators

1.2
/

Are You Uniquely Better? — determining what you should build vs buy

Four Insights Worth Reading

Acquiring the data is the cheap part
Scrapers and third-party sources took up 30% of our tech spend. The rest went to infrastructure and credits for storing, manipulating and verifying — and that's before headcount. You'd need at least three people to keep a dataset at "usable by a sales team," and in a slower-moving org, more. Build proposals price the scrape and the first delivery. Those are the two smallest numbers in the model.
Five data sources can cover 100% of your TAM and still miss a quarter of every market
One public company bought five sources. In aggregate they covered every single business in their target market. They consistently missed 20–30% of accounts anyway, because of how their pipeline joined the sources together. Coverage is directly related to how effective your entity resolution is, not of your vendor list.
"90% accurate" is a fiction
A single accuracy number averages a source's strengths and weaknesses into a figure that describes neither. Precision and recall are different problems with different costs: low precision burns rep time and kills trust; low recall shrinks the market you can work. Measure them separately, per field, never blended. Aim for 95% precision — below that, reps stop trusting the data and go back to researching by hand, and the asset you paid for is worth roughly nothing.
Analysis that's 100% correct today is wrong in three months
Sources change format silently. Businesses close at 22–25% a year. Mobile numbers change hands at 5%+. A scrape that works today breaks without telling you, and the failure shows up as reps quietly not connecting rather than as an alert. Refreshing the data and maintaining the method are two different jobs, and refresh cadence is an economic decision, not a technical one — which is why someone has to own the health of the dataset by name.