A molecular biology lab at AstraZeneca spent six years building its own software. Here's what they learned.

Six years ago, a four-person team at AstraZeneca's Gothenburg site was receiving plasmid construct requests through a mix of Excel files, Word documents, and email. They could produce about 300 constructs a year, but demand was climbing toward 3,000.

Liam Thompson, Senior Research Scientist at AstraZeneca, shared the story at Benchling's Nordic Digital Science & Innovation Day. In his session, he shared an honest account of what building and maintaining your own lab software costs over time, what brought his team back to Benchling after trying both paths, and three practical questions every team should ask before deciding their own strategy.

When demand outpaces process

Thompson's team supplies plasmids to AstraZeneca's Cambridge and Gothenburg sites, the starting material for proteins used in early drug discovery. The lab process itself was well defined: DNA or protein sequences are fragmented to reduce synthesis costs, sent to an external vendor for 7–10 days, then assembled into a plasmid, transformed into bacteria, and sequenced — a three-week cycle from request to verified plasmid. The team found that request management, not the lab process, was where they struggled to scale.

The initial build

They looked at Benchling first for request management, but at the time its request system didn't cover what they needed. So AstraZeneca's newly formed digital solutions team built its own request portal instead — covering expression host selection, vector choice, purification tags from an internal DNA library, and status visibility for scientists tracking their requests. Custom codon optimization and fragmentation logic followed, built to fit the specifics of the process.

It worked. So the team kept building on it. And that is where the real cost began to show up.

The hidden considerations of a custom build 

Several structural issues surfaced over the following years. Funding was tied to a specific project rather than ongoing maintenance, so once the initial development period ended, the team was left supporting a system without a corresponding long-term budget. 

"Software needs long-term funding, not just short-term project funding," Thompson said. "Just keep that in mind before you develop something yourself."

Developer turnover added further strain. Losing developers meant losing institutional knowledge of the system, causing long delays and contributing to technical debt, since new developers couldn't simply pick up where the previous ones left off. Thompson also noted the absence of automated testing. Without it, changes carried unclear downstream effects, and the team spent significant time addressing issues as they emerged rather than anticipating them.

With no clear stopping point, the team kept adding features long after the portal had solved its original problem. "We should have developed the request portal and stopped there," Thompson said. "Now we have something that took years to develop and a lot of money, and we're not using it because it doesn't fulfill our needs anymore."

What actually determines build vs buy

Instead of continuing to patch a system that wasn't working, the team started folding parts of the workflow back into Benchling. The product had expanded significantly since their initial use, and Thompson's team began using plates and inventory features for batching, and Benchling AI for tasks like plate reformatting and clone selection — work that previously involved hours of manual data handling in spreadsheets. "That saved us a lot of pain," he said.

This wasn’t really a build-versus-buy question. Instead, Thompson explained, it pointed at much more specific questions leaders need to consider when purchasing a platform. These include:

• Does a commercial platform meets the needs of the company?

• Might a custom tool add more value?

• How do cost, functionality, data handling, and team adoption factor into the decision to build versus buy?

The answer to each will shift as your team, data, and needs evolve. 

Automate the process you want, not the one you have

Thompson's central recommendation was to automate the process a team wants to run, not the one it happens to be running. "You're missing the opportunity to automate away the inefficiencies you have in your process," he said. He recommended defining the target process and data model before deciding on a tool.

 Three lessons followed from the Gothenburg team on how to develop automated workflows: 

• Document the data model, since undocumented logic becomes fragile as teams change over time. 

• Avoid using custom code to fill every gap in a vendor platform, since that code requires ongoing maintenance. 

• Design automation to handle exceptions, such as failed wells, low sample volumes, and instrument downtime.

Six years on, the Gothenburg team has a system that fits its current needs and a clearer read on where Benchling fits relative to what they build themselves. Thompson still isn't against building things in-house. He's against building them without first asking whether they should.

Curious about the technical side of AstraZeneca's construct generation process? Read the earlier case study on how AstraZeneca built its automated DNA assembly framework, covering the fragment-recycling approach behind their cost and speed gains.

Want to build automated workflows for your team? Request a demo to explore how Benchling AI can help teams improve efficiency and hit milestones faster.