Every engineering team hits this meeting eventually. Someone looks at a data enrichment quote, leans back, and says the sentence: “We could build this ourselves.”
And here’s the annoying part. They’re right. You CAN build it. Scraping, matching, a few data sources, an internal API. None of it is rocket science.
But “can we build it” was never the question. The question is what it costs to keep it alive in year two. I’ve sat on both sides of this decision, once as the person who inherited the homemade version. So let me lay out the honest math.
đź“Ś Short answer: Buy the data, build the thin logic layer on top (your matching rules, provider order, overwrite policies). Build more than that only if data IS your product, or your requirements are genuinely unusual. For standard firmographics and contacts, buying wins on speed and total cost almost every time.
What are you actually deciding?
You’re deciding which of three very different projects to take on, because “build enrichment” means three separate things:
- Build the data. Collecting and maintaining company and contact records yourself, through scraping and public sources.
- Build the pipeline. Buying data from providers, but building the matching, chaining, and CRM-sync machinery around it.
- Build the glue. Buying both data and tooling, and wiring it into your systems.
Almost nobody should do the first. Plenty of teams reasonably do the second. Everyone does the third.
And here’s the thing I’ve watched over and over: most build-vs-buy arguments are two smart people arguing about different rows of that list. Pin down which project you’re debating before you debate it.
Build vs buy at a glance
So how do the two paths compare, dimension by dimension? Here’s the honest scorecard:
| Dimension | Build | Buy |
|---|---|---|
| Time to value | A quarter or more, optimistically | Days to weeks |
| Upfront cost | Engineering sprints | Subscription or per-record fees |
| Ongoing cost shape | Permanent maintenance tax in eng time | Fees that scale with volume |
| Control | Total, over everything, forever | Limited to config and vendor choice |
| Coverage | Only what you can collect | Provider databases, re-verified at scale |
| Compliance exposure | All yours, no contract to point at | Shared, with a vendor paper trail |
| Year-two owner | A named engineer (or it dies) | The vendor, mostly |
Where building wins
Building wins when enrichment is close to the heart of what you sell. Four situations make the build case real:
- Data is your product. If customers pay you for data or intelligence, parts of the collection layer can be genuine strategy. You’re not saving money; you’re building a moat.
- Truly unusual requirements. A niche region no vendor covers well, exotic fields, extreme latency needs. When no provider serves the need, the argument settles itself.
- Extreme volume. At very high record counts, per-record pricing can flip the math. Can, not will. Run it with maintenance included.
- Existing muscle. A team that already runs crawlers and matching infrastructure pays a much smaller build premium than one starting cold.
Notice what’s not on that list: “the vendor quote looked expensive.” A quote is one year of visible cost. A build is many years of partly invisible cost.
Where buying wins
Buying wins whenever the data you need is standard and the clock is running. Which describes most teams, honestly.
- Standard firmographics and contacts. Industry, headcount, revenue bands, verified emails. Providers re-verify millions of records on infrastructure built for exactly that. Your two-person data team won’t match it.
- Speed. Buying works this quarter. Building works, optimistically, next quarter, and improves after that. Pipelines don’t wait politely.
- Verification at scale. Collected records start rotting the day you collect them. The decay math doesn’t care who built the database; vendors just have a bigger mop.
- A compliance paper trail. A vendor contract, documented sourcing, a processing agreement. When legal asks where a record came from, you have an answer that isn’t “our scraper.”
- Small teams. Every sprint spent on enrichment plumbing is a sprint your actual product loses. For a small team, that opportunity cost decides the whole debate.
What’s the same either way
Both paths leave you owning more than most teams expect. This is the part vendor decks and build proposals both skip, so let’s not. Whichever door you pick, data quality stays your job. A vendor can hand you fields, but only you know which records your team actually trusts.
Someone still owns match-rate monitoring. A person still writes the overwrite rules (does new data clobber old fields, or only fill empty ones?). And somebody still sets refresh schedules and checks that they ran.
Data decays on both paths. Compliance responsibility never fully transfers either. Under GDPR you’re the data controller whether the record came from your crawler or a vendor’s API. Buying shrinks these jobs a lot. It doesn’t delete them.
So budget an owner either way. The difference is whether that owner spends hours per week or per quarter.
The real cost math
The whiteboard estimate covers version one. That’s the trap. Total cost of ownership (TCO, the full cost over the system’s life) hides in the lines the whiteboard never shows:
- Source breakage. Sites change markup, block scrapers, deprecate formats. Monthly. The build is an event; the upkeep is a subscription paid in engineering time.
- The decay treadmill. Records need re-verifying forever, not once.
- Matching edge cases. “Just match the company names” launches a thousand exceptions: suffixes, rebrands, subsidiaries, international spellings. There’s a reason fuzzy matching company names is its own discipline.
- Compliance work. Scraped personal data means legal reviews you do alone.
- Opportunity cost. The roadmap features that didn’t ship. Usually the biggest line, and never written down.
→ True build cost = version 1 + (maintenance × every year after) + the roadmap work those sprints displaced
Run that formula honestly and the “free” build stops looking free. Sometimes it still wins. But now you’re deciding with real numbers.
đź’ˇ Before any vendor call: model your TRUE annual volume, not the demo volume. Per-record pricing that looks cheap on a 5,000-row pilot can look very different at your real yearly throughput. Price the whole year, then compare it to an engineer's loaded salary.
Five questions that decide it
Want to skip three meetings? Answer these five questions in writing first:
- Is enrichment your differentiator or your plumbing? If data quality IS the product you sell, building parts of it can be strategy. If it feeds your CRM, it’s plumbing. Buy plumbing.
- Are your requirements genuinely unusual? Niche region, exotic fields, extreme latency that no vendor serves well: the build case strengthens. Standard firmographics and contacts: it collapses.
- What’s your honest volume? At low volume, API pricing beats an engineer’s salary comfortably. At very high volume, the math can flip. Run it with maintenance included, not just build cost.
- Who maintains it in year two? Name the person. If the answer is “the team will absorb it,” the build is already dead. It just doesn’t know yet.
- How fast do you need it? If the pipeline needs data this quarter, the decision is made for you.
Three or more answers pointing the same direction? That’s your answer. Ties break toward buying, because buying is reversible and building mostly isn’t.
The hybrid that usually wins
The pattern I’ve seen succeed repeatedly: buy the data, own the logic.
You buy the commodity layer, the data itself, through enrichment APIs. Collecting and re-verifying millions of records is a scale game you can’t win at home. And you build the thin layer where your judgment lives: which providers to chain in what order (a waterfall setup, where a second source catches what the first missed), your matching rules, your overwrite policies, your field standards.
That layer is small, genuinely yours, and portable. If a vendor disappoints, you swap the provider without rebuilding the system. All the control that mattered, a fraction of the maintenance.
Whichever mix you land on, run the vendor side through the same selection criteria as any data purchase. Sample test on YOUR records first, contract second.
The year the homemade pipeline died on me
Story time. At one Hamburg job, I inherited a scraper-based enrichment pipeline that a long-gone engineer had built over two proud sprints. For a while, it was great. Free data, full control, everyone happy.
Then he left. Within one quarter, two of the five sources changed their markup and quietly broke. Nobody noticed for six weeks, which means six weeks of half-empty records flowed into the CRM. Our match rate on new accounts dropped so far that the sales team started keeping their own spreadsheets again.
Fixing it needed an engineer we didn’t have. So the “free” pipeline sat broken while we ran a vendor evaluation we could’ve run a year earlier. The subscription we ended up signing cost less than the two sprints the original build had eaten. I’ve never trusted a whiteboard estimate since.
🧠Compliance warning: scraped personal data under GDPR is YOUR legal exposure, with no vendor contract to point at. The GDPR framework and the UK ICO guidance both put controller responsibility on you. Company-level data is safer ground; the moment emails and titles enter a home-built pipeline, so does the risk.
How I know this (and what to check yourself)
This framework comes from sitting on both sides: running vendor evaluations, and living with an inherited build. The wider data world tells the same story. Fivetran’s build-vs-buy pipeline breakdown, Monte Carlo’s data stack guide, and Zyte’s four roads to web data all land on versions of the same warning: the build estimate is the cheapest number you’ll ever see for the build.
One honest limit: your volume math is yours. Prices, coverage, and your engineering capacity all shift, so re-run the five questions with current numbers before you commit either way.
Frequently Asked Questions
What does build vs buy mean in data enrichment?
It’s the choice between developing your own enrichment capability in-house or paying a vendor for it. In practice there are three sub-decisions: build the data itself, build the pipeline around purchased data, or just build the integration glue.
Is it better to build or buy?
Buy, for most teams, most of the time. Building only makes sense when data is your product, your requirements are truly unusual, or your volume is extreme enough to flip the per-record math. And even then, run the year-two maintenance numbers first.
Is it cheaper to build your own data enrichment?
Rarely, once maintenance is priced in. The build estimate covers version one; the real cost is the permanent engineering tax of keeping sources, matching, and freshness alive. At most volumes, per-record API pricing beats an engineer’s salary comfortably.
Can you combine building and buying?
Yes, and the combination is usually the right answer. Buy the data through APIs, and build the thin orchestration layer that encodes your rules. You keep control where control matters and outsource the scale game you’d lose anyway.
What’s the biggest hidden cost of building?
Opportunity cost. Maintenance hours are annoying but countable; the sprints your product roadmap loses to enrichment plumbing are the expense nobody puts on the whiteboard. And the one leadership regrets a year later.
It’s time to argue with numbers
Before your next build-vs-buy meeting, do both homework assignments. Get real API pricing at your true annual volume. And write the year-two maintenance plan for the build, with a named owner at the top.
Nine times out of ten, one of those two documents ends the debate on contact.
You’ve got this. Tell me in the comments which side of the debate you’re on right now, and whether year two has a name attached yet.
