Every mid-size life-science company hits the same wall around Series B or the first profitable year: the data you need to compete lives in fifty places, none of them talk to each other, and the answers your team needs take days instead of seconds.
So you do the natural thing. You decide to build. You post a req for a data engineer. Then two. Then a platform lead. Eighteen months later you have a team, a half-finished pipeline, and the same unanswered questions — just with a bigger burn rate.
The build-vs-buy decision in life-science data is one of the most expensive calls a technical leader makes, and most people frame it wrong. Here's the actual math.
What "build" really costs
Start with people. The median US data scientist base wage was about $112,590 in May 2024, software developers about $133,080, and ML/research scientists about $140,910 — base only. [1] Fully loaded with benefits (BLS data puts benefits at roughly 42% on top of wages [2]), a blended mid-to-senior head runs ~$180K–$224K. A five-person team is roughly $0.9M–$1.6M/year; ten people is $1.8M–$2.2M+.
And you're competing for that talent against companies that don't pay in base salary. Levels.fyi pegged 2025 median software-engineer total comp at $226K, rising to $457K at staff and $551K at principal — driven by equity you can't easily match. [3] A mid-size diagnostics company is not out-bidding a hyperscaler for a staff platform engineer.
What "build" usually delivers
Now the uncomfortable part: the failure rate. Gartner predicts 80% of data and analytics governance initiatives will fail by 2027. [4] And the team you did hire won't spend its time on the differentiated work — Anaconda's survey found data scientists spend about 45% of their time just loading and cleaning data before any modeling begins. [5] You hired for models and got a cleaning crew.
Why "buy" disappoints too
So you buy a platform instead. This is where the integration gap eats you. MIT's 2025 study found roughly 95% of enterprise generative-AI pilots produced no measurable P&L impact — and the gap was almost never model quality. It was the failure to wire the tool into real workflows and data. [6] A generic platform assumes a standardization that life-science data simply doesn't have: every registry uses different identifiers, your internal data model is bespoke, and the same molecule, device, or product wears a different name in every system. (We've written about that entity-resolution problem at length.) Off-the-shelf software lands in your org and discovers it doesn't fit — exactly the 95% trap.
The third option operators miss
The framing "build a team OR buy a product" hides a third path that the most data-mature companies in tech have already converged on: embed the engineering. The Forward Deployed Engineer model — an engineer who works inside your team to learn the domain and ship the specific integrations a generic product can't — has gone from a Palantir specialty to, in a16z's words, "the hottest job in tech," with FDE postings up roughly 729% year over year and OpenAI launching a $4B+ deployment company built around ~150 of them. [FDE-2] [FDE-3]
The reason it works for mid-size life-science companies is structural. You don't need a permanent 10-person platform team to maintain infrastructure you'll touch quarterly. You need someone who has already built the hard, reusable parts — the public-data pipelines, the identity resolution, the normalization layer — and who embeds to wire those into your specific workflow. You get the integration depth of "build" without the $2M standing payroll, and the leverage of "buy" without the 95% misfit rate.
How to actually decide
A clean heuristic for technical leaders: build the thing that is your actual differentiation and that you'll iterate on weekly. Buy or embed everything that is undifferentiated heavy lifting — public-data ingestion, entity resolution, normalization, the semantic layer underneath your AI. If your engineers are spending 45% of their time cleaning ClinicalTrials.gov exports, you are building the thing you should have bought, and starving the thing you should have built.
The question isn't "can we build this?" Your team can build almost anything. The question is whether the data plumbing is where you want your best engineers spending the next eighteen months.
Where is your team's time actually going — the differentiated product, or the data cleaning underneath it?