The spreadsheet that runs a critical process is a risk, not a system.
Biotech applications formalise the scientific and operational workflows currently held in spreadsheets and scripts — built to survive the audit that arrives with the first clinical trial.
Most biotech application projects begin with a file that started as a convenience and became infrastructure: sample tracking, assay results, a screening cascade, a compound registry. It works until several people need it simultaneously, until a version diverges, or until someone asks who changed a value and when. Understanding exactly what that file does — including the informal conventions that are not written anywhere — is the real specification, and skipping that step is why replacements so often fail to displace the spreadsheet they were meant to retire.
Laboratory information management, electronic notebooks and inventory systems are mature and rarely worth rebuilding. What is genuinely unique to a biotech company is the specific workflow around its platform or modality — the assay cascade, the decision logic, the way results feed a go or no-go. Building software is justified for that and hard to justify for the rest. Companies that build broadly end up maintaining a great deal of undifferentiated software with a small team, which becomes an obstacle precisely when the science starts moving faster.
Assay results, sequences, structures, imaging and instrument output do not fit comfortably into the tabular models that most application frameworks assume. Instrument files are large, formats are proprietary and often undocumented, and the same measurement may need several representations. Deciding early what is stored as structured data, what is kept as a file with metadata, and where the boundary sits determines whether the system is still workable at ten times the current volume. It is also the decision most commonly deferred and most expensive to revisit.
A discovery-stage company builds without regulatory constraint, and then a partner’s due diligence or a first regulatory interaction asks how data integrity is assured, who could change a result and whether that would be visible. Systems built without an audit trail cannot answer retrospectively. Including immutable history, user attribution and a defensible account of how a value came to be recorded is inexpensive when designed in and effectively impossible to add afterwards — and it tends to be needed a year earlier than anyone expects.
Biotech teams turn over as programmes advance and funding arrives, and the scientist who commissioned an application is frequently not the one relying on it two years later. Software that depends on undocumented understanding becomes unmaintainable exactly when the company can least afford it. Conventional technology choices, documentation written for a successor rather than for the current team, and no dependence on a single individual are unglamorous decisions that determine whether the system survives the transition or is quietly abandoned back to spreadsheets.
Application projects in small companies fail more often from ambition than from execution. The version that ships and gets used is the one that solves the single most painful workflow completely, rather than the platform intended to solve everything eventually. Scoping to the process where a delay or an error genuinely costs the programme — and deliberately leaving adjacent processes alone until that one is working — is what makes the difference between software your scientists rely on and a project that consumes a year and is remembered as an overhead.
What comes up when scoping bespoke software for a research-stage company.
Buy the standard functionality and build only what is specific to your platform. Sample tracking, inventory and general notebook functions are solved problems, and rebuilding them consumes budget without creating any advantage. Where commercial systems genuinely struggle is the workflow unique to your modality or your assay cascade. The common and effective pattern is a purchased system for the general case with a focused application handling the part that is actually yours.
You need the technical foundation now even if the formal obligation comes later. Immutable history, user attribution and a record of how a value changed cost very little when built in and cannot be reconstructed retrospectively. The moment they are needed — a partner’s due diligence, a first regulatory interaction, an unexpected result requiring investigation — usually arrives sooner than planned, and the answer at that point is either available or it is not.
By treating the spreadsheet as the specification rather than the enemy, and by making import and export genuinely easy. Scientists rely on spreadsheets because they are fast and flexible, and an application that is slower for daily work will be circumvented. Systems that succeed usually let people continue to work in a familiar way for analysis while holding the authoritative record centrally — the argument is not worth having, and it is not the one that matters.
Conventional technology choices, documentation aimed at someone who has never seen the code, and no reliance on a single person’s understanding. The specific temptation in biotech is to build on whatever a computational scientist prefers, which produces something only they can maintain. Choosing widely understood tooling, even where a specialist framework would be marginally better, is what keeps the system supportable through the turnover that this sector guarantees.
A spreadsheet three people edit simultaneously that now holds something the programme depends on, and no answer to who changed a value last March. Tell us which process is causing the most pain and we will tell you what is worth building and what is not.