What a Biotech Under 200 People Should Not Build In-House

Why the Build Question Keeps Coming Back at This Size

Small and mid-size biotech companies now carry a large share of the industry’s science. Emerging biopharma companies account for about 65 percent of the molecules in the research and development pipeline where no larger company is involved, up from 50 percent in 2016 and 34 percent in 2001, and they originated 55 percent of new active substances launched over the past decade.¹ The pipeline has moved toward companies that do not have the internal functions large pharma takes for granted. Industry trend data on emerging therapeutic companies shows the same pattern from the investment side: a large population of research-stage companies, most of them pre-revenue, most of them running lean.²

That combination produces a specific pressure. The science is sophisticated. The regulatory expectations are the same ones a top-twenty company faces. The headcount is not. So when a process needs a system, the company faces a question that a larger organization would never ask out loud: could we just build this ourselves?

The answer is usually yes, technically. Someone in the company can build it. Biotechs are full of people who write good code: computational biologists, bioinformaticians, process engineers who taught themselves scripting because the alternative was another week of manual work. The build is not the hard part. The build is the cheapest, shortest, most enjoyable part of the whole thing, which is exactly why it is such a poor basis for a decision.

The three ways companies end up with software they did not decide to build

In practice, custom systems at this size arrive through three doors, and only one of them is a decision.

The first is the pilot that worked. Someone builds a small tool to solve an immediate problem. It works. People start using it. A year later it holds data that supports a regulatory submission and nobody remembers agreeing to that.

The second is the gap between two bought systems. The company buys two commercial products, discovers they do not talk to each other in the way the process needs, and writes glue to bridge them. The glue is small, so nobody treats it as a system. It then becomes the single point through which the company’s most important records move.

The third is a real decision, usually made because a commercial product genuinely does not exist for what the company does. This is the only one of the three that deserves to be defended, and it is by far the rarest.

The first two doors account for most of the custom software in most small biotechs. Neither involved a comparison of long-term effort. Both produce the same obligations as the third.

What “Build” Actually Obligates You To in a Regulated Company

The commercial argument for building is that you avoid a license fee and get exactly what you want. Both are true. Neither is the point. The point is what you take on the moment the software touches a regulated record.

GAMP guidance, the framework most life sciences quality organizations use to scale validation effort to risk, sorts software into categories and treats custom-developed applications as the category demanding the most rigor: a full development life cycle, with specification, design, code control, and testing documented and defensible.³ The guidance also reflects a practical reality that matters here. Where a commercial supplier has already produced development and testing evidence, a regulated company is encouraged to make use of it rather than repeat it. When you build the software, there is no supplier evidence to make use of. You are the supplier and the regulated company at the same time, and you have to produce both sets of records.

Regulators have said a version of this for a long time. FDA’s software validation guidance, written for device manufacturers but widely read across life sciences, sets out the expectation that software used in production or as part of the quality system is validated for its intended use, with the level of effort matched to risk.⁴ FDA’s final guidance on computer software assurance, issued in September 2025, reissued February 3, 2026, and scoped to production and quality management system software under the device quality management system regulation, moves further toward risk-based assurance and away from documentation for its own sake.⁵ Read carefully, neither document lowers the bar for custom software. They both raise the bar for thinking. Risk-based assurance means you must be able to explain, in writing, why the assurance you performed was enough. For a system you wrote yourself, that explanation has to cover the developers, the code, the environment, and the change process, because there is no third party who has covered any of it for you.

On the pharma side, the obligations attach to the record rather than the tool. Laboratory records must contain complete data derived from all tests, including the identification of the person who performed each test and a record of any calculation performed, with the retention and review expectations that follow.⁸ Health Canada’s guidance on computerized systems, which follows the Annex 11 structure, is explicit that validation documentation must cover the relevant life cycle stages, that user requirements should describe the required functions and remain traceable across the life of the system, and that formal agreements must exist with third parties who provide computerized system services, with duties stated clearly.⁶ When there is no third party, there is no agreement to write. There is only your own quality system, absorbing the whole obligation.

You still own the configuration even when you buy

It is worth being honest about the limit of the buy argument. Buying a validated commercial product does not transfer your obligations to the vendor. It transfers the development evidence, not the operation.

An FDA warning letter issued in August 2025 makes the point plainly. The firm was using a widely deployed commercial chromatography data system. FDA’s finding was not about the software. It was that the firm did not review audit trails and raw analytical data captured by the instruments, had no written procedures to review electronic data or integration to ensure data reliability for batch release, and failed to appropriately control administrative privileges for file modification and deletion in that system.⁷ Every one of those findings is a configuration and oversight failure by the user, not a defect in the product.

So the correct statement is narrower than “buying is safer.” Buying moves a specific and large piece of work off your plate: the development life cycle evidence, the ongoing patching of the application, and the qualification of the people who wrote it. It leaves you with configuration, access control, audit trail review, data review procedures, and periodic review. Building leaves you with all of it.

The Never-Build List

The never-build list is short and it is not a matter of taste. A category belongs on it when three conditions hold at once: mature commercial products exist and are widely deployed in regulated companies; the regulatory expectation for that category is well settled, so there is no interpretive advantage in doing it your own way; and the ongoing obligation is heavy relative to any benefit from tailoring.

Why the reasoning matters more than the list

Lists age. The reasoning does not. Four burdens attach permanently to anything you build, and they are the reason the categories above are not close calls.

You carry the validation forever, not once. The initial qualification is the small part. Every change to a custom system triggers your change control process, your impact assessment, your regression testing, and your record. A vendor amortizes that work across a customer base. You amortize it across one company.

You carry the patching. Modern applications are assembled, not written. Census III, which drew on more than twelve million observations of open source libraries in production applications at more than ten thousand companies, found that much of the most widely used open source software is maintained by only a handful of contributors, that legacy versions persist across the ecosystem, and that individual developer account security has become a first-order concern.¹⁵¹⁶ Your custom application is built on top of that reality. Somebody has to track advisories for every component, decide what to update, and re-test the validated state afterward. If nobody has that job in writing, the answer is that nobody is doing it.

You carry the qualification of your own developers. This is the obligation companies forget entirely. When a vendor writes the software, their development competence is assessed once through supplier assessment. When your scientist writes it, that person’s training record, their competence for the task, their access to the production environment, and the segregation between who wrote the code and who approved it all become part of your quality system. Health Canada’s guidance is direct about the need for formal, documented arrangements with anyone providing computerized system services.⁶ An internal builder is not exempt from the underlying principle. They are simply harder to document, because the person who wrote the code, tested it, and approved it into use is frequently the same person.

You carry key-person risk permanently. Software engineering research has a name for this. The bus factor is the minimum number of people whose sudden departure would stall a project, and a survey of 269 engineers found it is widely perceived as a real problem in collective development.¹³ In a 60-person biotech, the bus factor on an internally built system is almost always one. That single person is usually also the only one who understands why a particular calculation is written the way it is, and that reasoning is often undocumented because it lived in their head during a week when the priority was getting the tool working.

Configure, Do Not Author

Between never-build and genuinely-custom is the largest and most productive category: work you should do yourself, inside systems you bought. This is where a small company’s knowledge of its own processes creates real value, and where the effort of ownership stays proportionate.

The distinction is simple. Configuration uses the capabilities the product already includes and the vendor already tests. Authoring adds code the vendor has never seen and will not test on your behalf. The first stays inside the supplier’s evidence. The second steps outside it, and once you are outside it, you are building, whatever you call it internally.

The four configuration decisions that matter most

Workflows. The way a deviation moves from opening to closure, who can approve at each step, and what evidence is mandatory at each transition. This is your process, and no vendor knows it. Configure it deliberately and write down why each gate exists, because those reasons are what you will explain during an inspection.

Forms and required fields. Nearly every data quality problem in a small company traces back to a field that was optional when it should have been mandatory, or free text where a controlled list belonged. This is a configuration decision with permanent effects on every downstream report.

Reports. Report definitions are where the same question acquires three different answers across three systems without anyone noticing. Define the calculation once, in writing, and configure each report to match the definition rather than defining it separately in each tool.

Integrations between bought systems. Prefer vendor-supported connectors, and treat an unsupported integration as authored code with all the obligations that follow. A small biotech’s integration estate is one of the few places where a modest amount of deliberate design saves years of trouble.

The data model choices inside those systems. Batch and lot identifiers, sample naming, product hierarchy, site codes, and study identifiers. These are set once, early, usually by whoever configured the first system, and they determine whether your systems can ever be joined. Getting this right is the highest-value configuration work a small company does, and it requires no code at all.

Replacing spreadsheet-based processes deserves a related note, because it is the most common trigger for an unplanned build in a QC lab or a small quality function. The instinct is to write an application. The better first move is usually to see whether the process fits a system you already own. That question, and the six-week approach to answering it, is worth treating as its own exercise rather than folding it into a build decision.

Where Custom Work Genuinely Pays

There is a real category here, and dismissing it would be as wrong as building everything. Custom work pays in the few places where a company’s actual scientific or operational differentiator lives, and where nobody sells the thing you need because nobody else needs it in that form.

Three shapes recur.

1. The analysis pipeline that encodes your science

If your company’s advantage is a way of processing assay data, calling variants, scoring images, modeling a formulation, or interpreting a signal that competitors do not have, that pipeline is the company. Buying a general-purpose tool and forcing your method into it is not a saving. It is a dilution of the only thing you own.

Build it. Then treat it as a real system: version control, code review by someone other than the author, documented method rationale, controlled environments, and a validation approach scaled to how the output is used. A pipeline whose output supports a regulatory filing carries the same expectations as any other system producing regulated data, and the calculation performed on the data has to be recorded and traceable.⁸

2. The internal data product nobody sells

The second shape is a data product: a joined view across systems that answers a question your operating model depends on. Batch genealogy across a contract manufacturing network, a per-program view of every open quality record, a study-level readiness picture built from four different sources. Vendors sell the sources. Nobody sells the join, because the join reflects how your company is organized.

This is worth building, with one condition. Build it as a read-only analytical layer that draws from the validated systems of record rather than as a system that creates or holds the record itself. That single design decision changes the obligation dramatically. A reporting layer that reads validated data and produces management information carries a much lighter burden than a system that originates a GxP record, and it is far easier to change as the company grows.

3. The integration nobody sells

The third is a genuinely unavailable integration between two products, or between an instrument and a system, where the vendor has no connector and no plan to build one. Sometimes this is real. When it is, build the smallest possible bridge, document the interface contract, test the failure modes rather than only the happy path, and give it a named owner. Integration patterns between laboratory and manufacturing systems deserve their own treatment, particularly the question of which system holds the truth when two of them disagree.

The Decision Framework: Five Questions Before Anyone Writes Code

Most build decisions in small companies are made on a comparison of a license quote against an estimate of internal effort for version one. That comparison is wrong in a predictable direction, because the license quote covers years and the effort estimate covers weeks. The framework below forces both sides onto the same footing.

Making the comparison honest

Two adjustments make the effort comparison usable rather than theoretical.

Price the buy path completely too. Buying is routinely underestimated on the implementation side: configuration effort, data migration, validation of the configured system, integration work, training, and the internal time to run a selection process properly. A buy decision that only counts subscription fees is as dishonest as a build decision that only counts version one.

Convert recurring obligations into people, not money. At this size, the binding constraint is rarely budget. It is attention. Express the recurring work as a fraction of a person’s year: periodic review of four custom systems, change control for a dozen changes a year, patch assessment for the components underneath. When leadership sees that the custom estate consumes a third of someone’s year in perpetuity, and that this person is also the only one who can do it, the decision usually makes itself.

What an Acquisition or a Partnership Does to Your Custom Estate

For most emerging biotechs, the exit or the partnership is the point. That makes diligence the most useful lens available for a build decision, and the one least often applied while the decision is being made.

Here is what happens. A prospective acquirer or large partner asks for the list of systems supporting regulated activity. For each one, they ask what it is, who supplies it, whether it is validated, when it was last reviewed, and how changes are controlled. Commercial systems answer those questions in a sentence each. Custom systems generate a conversation.

The conversation goes badly in specific, avoidable ways.

The specification does not exist in the form they expect. Requirements were captured in a ticket system, or a shared document, or a conversation. The validation evidence references a version of the software that has since changed a dozen times.

The author has left. The remaining team can operate the system but cannot explain the design decisions inside it. Every question about why the calculation works a particular way produces an offer to find out and come back.

The change history is thin. Not absent, usually. Thin. Changes were made and tested, but the records are informal, and formality is exactly what the diligence team is checking for.

The integration turns out to be load-bearing. A script written in an afternoon, running on a schedule, moving data between two validated systems, with no owner, no specification, and no monitoring. It is discovered during diligence rather than during a system inventory, which is worse.

None of these findings kills a deal on their own. They do three things that matter. They extend the diligence timeline. They add remediation commitments to the transaction, which someone has to fund and complete. And they shape the acquirer’s view of how the company was run, which affects every other conversation in the process.

A defensible inventory of computerized systems is the foundation for all of this, and it is worth building on its own terms rather than assembling under deal pressure. The same is true of a structured approach to technology diligence, which is a well-understood discipline that a small company can borrow from long before it needs it.

Fractional and Outsourced Leadership: Who Owns What

A company of 60 or 120 people cannot usually justify a full-time head of IT, and it certainly cannot justify a full-time head of quality systems alongside a head of quality. The work still exists. What changes at this size is not the amount of thinking required but the amount of doing, and those two things should be sourced differently.

The pattern that works is straightforward. Judgment, accountability, and vendor oversight stay inside the company, in a named person with real authority, whether that person is full-time, fractional, or a partner in a defined role. Execution goes to vendors and partners. The failure mode at this size is the opposite arrangement: an internal person doing hands-on execution while nobody owns the decisions, which is precisely how a company ends up with four custom systems that nobody chose.

What a fractional leader should actually be asked to do

The role is often set up badly. A part-time technology leader is hired and then given a queue of tickets, which wastes the capability entirely. At two days a month or one day a week, the right output is a small number of decisions that hold for a long time.

Own the map. One current list of systems, their GxP impact, their supplier, their owner, and their review date. Nothing else on this list is possible without it.

Own the standard. A written position on what the company builds, configures, and buys, so the next decision is made against a rule rather than a mood.

Own vendor oversight. Supplier assessment, quality agreement content, and the annual question of whether each vendor is still performing. Formal agreements with third parties providing computerized system services are an expectation, not a nicety.⁶

Own the escalation path. Who decides when a build is proposed, and who has the authority to say no. In practice this is the single most valuable thing the role provides, because the alternative is that build decisions are made by whoever is enthusiastic.

The partner side deserves the same discipline as the vendor side. A partner who delivers validation, configuration, or engineering work should be selected on the same evidence a software vendor would be: documented capability, defined deliverables, a quality agreement, and a stated position on what happens to the work product and the knowledge when the engagement ends. The purpose of using a partner at this size is to import capability the company will not staff permanently, not to move the accountability somewhere it cannot be exercised.

Conclusion

The build question at a biotech under 200 people is not really a question about software. It is a question about what the company is willing to own permanently. Every custom system is an obligation with no end date: validation that must be maintained, components that must be patched, developers who must be qualified, reviews that must be scheduled, and knowledge that must survive one person’s resignation. Commercial products do not remove those obligations, but they move a large and specific portion of them to a supplier whose business it is to carry them. That is the whole trade, and it is a good one for almost everything a small company needs a system to do.

What remains after the never-build list and the configure list is short, and that shortness is the point. Build the analysis pipeline that encodes your science. Build the joined view of your own operations that nobody sells. Build the integration that genuinely does not exist. Configure everything else deliberately, buy the rest, and put a named person in charge of holding the line, whether that person is on staff full-time or serving in a fractional role. The companies that do this well are not the ones with the most technology. They are the ones that can answer, in a single sentence per system, what they run, who supplies it, and who owns it.

Sakara Digital works with pharma and biotech organizations making these decisions with lean teams and real regulatory exposure. If you are weighing a build against a purchase, cleaning up a custom estate that grew without a decision, or deciding what a fractional technology and quality systems leader should own, we are happy to have that conversation.

For Further Reading