Build vs. Buy AI in Life Sciences: What to Build, and What to Never Build Again
Every technology wave reopens the same question, and agentic AI is no different. Here's how to answer it, from a room full of pharma leaders who discussed it in detail.
Last month I moderated a panel on build vs. buy for agentic AI in life sciences at DataDrivenPharma East in Boston. Earlier that day, one of the world's largest pharma companies presented a platform they'd built internally to harmonize and orchestrate research data across preclinical, clinical, real-world, and omics sources, with a conversational agent layer on top. They'd profiled tens of thousands of patients, captured proteomic time-series data, and cut feasibility questions from two or three weeks to thirty seconds.
The most instructive part of that talk was the Q&A, not the demo. The questions from the room circled the same theme:
- How long did this take to build?
- How many people?
- What happens to all that institutional knowledge when the people who built it leave?
- How did you get the organization to change how it works?
The presenter answered them candidly. The platform almost died six months in. While the CEO’s vision seemed easy on the surface, materializing it into the polished platform on the screen took years of effort and many challenging moments.
We've been here before
The build-versus-buy debate feels familiar because it is. Every technology wave reopens it: a wave of startups builds around the new capability, enterprises start layering it in, and the largest, best-resourced organizations decide they can do it better themselves and build internally.
That was my own experience at a large pharma company. I watched multiple dedicated FTEs spend years building an internal system, then watched it stall when the developers were assigned other priorities or left the company. When I brought this up on the panel, most of the room nodded as they had lived through the same phases.
We're in the same phase with AI. To be plain about where everyone sits: Manifold is one of the startups building the category, and the pharma on that stage is a resourced incumbent that chose to build. The question I find more useful than "who's right" is this: which parts of this should a company build in-house, and which parts should it never build again?
When should you build AI in-house?
The barrier to building has dropped dramatically. AI-assisted coding and maturing agent frameworks let a capable team stand up a prototype that looks like a platform in a fraction of the time it took two years ago. As the pharma presenter confirmed, AI-assisted development let them ship faster and at higher quality.
So some things you should build. Handing a vendor anything core to your competitive advantage, your science, your proprietary models, the questions only your data can answer, is a mistake. Control, customization, and IP ownership are legitimate reasons to build.
The hidden invoice: the real cost of building in-house
Here's what doesn't show up in the demo.
- Multi-year time-to-value. Internally built systems almost dying at six months is closer to the norm than the exception. The vision is easy, but the patience to see it through is expensive.
- Institutional knowledge risk. Over a multi-year build, the people who understand the platform will leave, and the knowledge leaves with them.
- Perpetual maintenance. Building the platform is the down payment. Keeping it current as models, governance, and data sources shift is the mortgage.
- Opportunity cost. Every scientist or engineer maintaining data plumbing isn't working on the next discovery. It's the most expensive line item on the build, and it never shows up in the budget even as it drains your scarcest resource.
What to build vs. what to buy: two layers, two answers
Treating this as a single decision is the mistake. Two layers are in play, and they call for opposite answers.
The first is the undifferentiated layer: data harmonization across messy sources, governance and access controls, agent orchestration, secure compute and tooling. Call it plumbing. It's hard, necessary, and nearly identical at every life sciences organization. Building it yourself means spending years and scarce talent recreating something with no competitive advantage. Nobody is first-to-market with a new drug because their data catalog was bespoke.
The second is the differentiated layer: which targets you pursue, what molecules you develop, which models you train, the proprietary insight you pull from your data. That is where you should pour everything, and that is the build worth investing in.
Build everything, and you spend the differentiated team's best years on the undifferentiated layer. By the time the plumbing works, the science is already behind.
Build vs. buy: five questions to decide
When a team asks me whether to build or buy, I push them past the binary with five questions.
- Is this layer a source of competitive advantage, or is it table stakes? Build the parts that set you apart. Buy the parts that don't.
- Do we have the talent to maintain this for five years, not just ship version one? Starting a build is easy. Sustaining one is where teams struggle.
- What's the opportunity cost? What does the team building the plumbing not get to work on?
- What happens when the people who built it leave? If the answer is "we're in trouble," that's a buy.
- How fast do we need this? If the answer is "this year," a multi-year build is a non-answer.
How Manifold fits into this
This is where I should be direct about where I sit. Manifold is one of several vendors competing for the "buy" side of this decision. Any of them will tell you some version of what I've argued above: build the differentiated layer, buy the undifferentiated one. The question worth asking here is what "buying the foundation" actually gets you.
Many pharma and biotech companies consider the legacy platform space as another system to learn or platform to move their data and compute, then end up with buyer's remorse once they see the upfront operational cost. Manifold is built to avoid that. We handle the governed data foundation, orchestration, and agent infrastructure, the unglamorous part that nearly killed the pharma presenter's project.
- Data harmonization across preclinical, clinical, real-world, and omics data without requiring you to restructure your existing data model.
- Deployment inside your own virtual private cloud so your data doesn't move into infrastructure you don't control.
- Governance and access controls built at the data layer, with SOC 2 Type II, GDPR, 21 CFR Part 11, GxP validation, HIPAA, and BAA ready.
- Agent orchestration that connects to your own institutional data, grounded in your methods, workflows, and questions.
Manifold sits on top of what you already have, so your team builds agents against it on your terms.
Where this goes next
A recurring theme from the panel was that there is a place and time for building systems in-house. You get the full ownership of the entire user experience and don’t have to deal with lengthy procurement processes. But ultimately, the teams who come out ahead are the ones who stay disciplined about what they invest in internally and buy the rest from the right partner, so their scientists stay on the science and drug discovery.
So this is what I will leave with: build the science, buy the foundation, and skip the three years it takes to rediscover why building that foundation is hard.
Build vs. buy AI: common questions
Should life sciences companies build or buy AI agents?
Both, on different layers. Build the parts tied to competitive advantage: your targets, models, and the questions only your data can answer. Buy the shared foundation underneath, meaning data harmonization, governance, orchestration, and secure compute, because building it yourself costs years without setting you apart.
We built our own agents in a few months. Do we still need a platform?
Standing up an agent is the easy part now, and a weekend prototype is not the hard problem. The hard problem is what comes after: running that agent on your real data, under your governance, connected to the rest of your stack, and keeping it current as models and data sources change. That is the engineering overhead a platform removes.
How long does it take to build an internal AI data platform?
Longer than the demo suggests. The pharma team on our panel said their platform nearly died six months in and took years to reach something usable. Time-to-value is measured in years, not quarters, and the maintenance never ends.
What are the hidden costs of building an AI platform in-house?
Four that rarely make the budget: multi-year time-to-value, institutional knowledge that walks out when key builders leave, perpetual maintenance as models and regulations shift, and the opportunity cost of scientists and engineers maintaining plumbing instead of advancing the science.
Does buying an AI platform mean moving our data?
It shouldn't. With a bring-your-own-cloud model, the platform runs inside your environment and your data never leaves your control, which is what keeps HIPAA, GDPR, and 21 CFR Part 11 obligations satisfied.
