"Should we build this or buy it?" is one of the most consequential questions an engineering leader answers — and one of the most poorly argued. The debate usually runs on vibes: the engineers want to build because building is fun, finance wants to buy because it's a line item, and nobody writes down the actual criteria.
Here's a framework you can run in about twenty minutes and defend in a board meeting. Six questions, a scoring rule, and a cost model that fits on a napkin.
The six questions
Score each from 0 to 2. Be honest; the framework only works if you don't flatter yourself.
- Is this your differentiation? Will customers ever choose you because of this capability? (0 = pure infrastructure nobody sees, 2 = this is the product.)
- How often will you change it? (0 = touch it quarterly or less, 2 = iterate weekly.)
- Does a real off-the-shelf option exist? (0 = mature products fit your case, 2 = nothing on the market actually does this.)
- Can you staff and retain the team? (0 = you can't compete for this talent, 2 = you already have the right people, with backup.)
- How bad is a failure? (0 = annoying, 2 = regulatory, safety, or revenue-critical.)
- Is the hard part reusable across companies? (0 = it's generic plumbing everyone needs, 2 = it's unique to your business.)
The scoring rule
Add it up (0–12):
- 0–4 → Buy. Undifferentiated, stable, well-served by vendors. Building it is ego, not strategy.
- 5–8 → Embed / hybrid. The hard parts are reusable but your integration is specific. Bring in the prebuilt foundation and customize the last mile — without standing up a permanent team. (More on that embedded-engineering model.)
- 9–12 → Build. This is your moat, you'll iterate constantly, nothing off-the-shelf fits, and you can staff it. Go.
Notice where most data-infrastructure work lands: questions 1, 3, and 6 usually score low. Public-data ingestion, normalization, and entity resolution are undifferentiated (every company in your space needs them), well-defined, and reusable across companies. They feel like building because they're technically hard — but technically hard is not the same as strategically yours.
The napkin cost model
Before you commit to build, price it honestly. A fully-loaded engineer (salary + ~42% benefits per US Bureau of Labor Statistics data [1]) runs roughly $180K–$224K a year at mid-to-senior level. So:
- 3 engineers ≈ $0.55M–$0.67M/year
- 5 engineers ≈ $0.9M–$1.1M/year
- 10 engineers ≈ $1.8M–$2.2M/year
Then apply two multipliers people forget. First, the maintenance tax: the team doesn't disband after launch — pipelines rot, sources change schemas, and someone has to babysit it forever. Second, the opportunity cost: every engineer cleaning data is an engineer not building your differentiation, and they'll spend a lot of time on it — industry surveys put data prep at ~45% of a data professional's time. [2] If the thing you're building isn't on the moat list, that spend is pure drag.
The three signals that almost always mean "don't build it"
- "Every company in our space has to solve this too." If it's universal, it's not differentiation — someone has already built it better than you will on a side quest.
- "We just need to get the data clean first, then we'll do the real work." That sentence has eaten more roadmaps than any other. The "just get it clean" part is the iceberg; mapping one dataset to a standard model took a median of 358 days in one peer-reviewed network. [3]
- "We can't really hire for this, but we'll figure it out." If question 4 scored a 0, building is a staffing bet you've already told yourself you'll lose.
Why the default is "build" — and why that's a trap
Engineering teams default to build because building is the thing they know how to do and enjoy doing. But the macro evidence is unkind to that instinct: Gartner predicts 80% of data and analytics governance initiatives will fail by 2027 [4], and MIT found roughly 95% of enterprise AI pilots produced no measurable P&L impact, mostly from the integration gap rather than weak technology. [5] The winning move is rarely "build everything" or "buy everything." It's drawing a sharp line: build your moat, and acquire — buy or embed — the undifferentiated foundation underneath it.
Run the six questions on your current biggest project. Where did it score — and are you building something that's actually yours?