How to Choose a Life Science Software Development Partner: 20 Questions to Ask
Hiring a software developer for a laboratory, an instrument or a regulated process is a different decision from hiring one for a website. The software will be judged by whether its numbers are right, whether an inspector accepts its records, and whether it still runs in ten years, and a partner who has never faced those tests will not know what they involve until your project fails one. This article gives twenty questions to ask a prospective partner, grouped by what they reveal, with a description of what a good answer looks like and the warning signs to listen for. At the end is a checklist you can paste into a request for proposal. The questions are demanding on purpose. A partner who welcomes them is the one you want.
Why scientific software needs a different kind of partner
Three things separate scientific software from the rest. The output is a measurement, so correctness is not a matter of opinion and cannot be judged by looking at the screen. The environment is often regulated, so the development process itself is evidence that will be inspected. And the lifetime is long: instruments and assays run for a decade or more, through operating system changes, staff changes and regulatory changes.
General software agencies are organized around none of these. They are good at interfaces, integrations and delivery cadence, and they price in the time to learn what an assay is. Some do learn. But the questions below are designed to find out, before the contract is signed, whether a partner already understands the science, the compliance and the lifetime, or is planning to understand them at your expense.
Questions about the science
1. Who on your team has done this science, and what did they do? You are looking for named people with laboratory or analytical backgrounds who will be on the project, not a slide about “domain expertise”. A good answer names the scientist, the technique and the years.
2. Show me analysis software you have shipped, and tell me how you know its numbers are right. The answer should include a product or a project, the method used to establish accuracy (reference datasets, comparison against a validated method, published validation), and an admission of the cases where it does not work. A partner who has never had to defend a measurement will not have an answer.
3. How will you establish that the algorithm works on our data, not just on yours? Look for a plan: obtaining representative data early, defining acceptance criteria with you, testing across the range of sample quality you actually see, and reporting failures rather than hiding them behind a demonstration.
4. What happens when the science changes halfway through? Assays evolve, instruments get upgraded and requirements shift. The answer should describe how change is scoped, priced and validated, not promise it will not happen.
Questions about compliance
5. Which of your products or projects run in GMP-regulated environments today, and who has audited them? Names matter, within the limits of confidentiality. A partner whose software has been through the regulatory departments of large pharmaceutical companies has been asked every question an inspector asks.
6. Map your standard compliance components to 21 CFR Part 11 and Annex 11. A good partner has this document ready: audit trail, electronic signatures, access control, record protection, copies, checks and validation evidence, each tied to the regulation section. Our GMP compliant software article lists the nine controls to expect.
GMP compliant software article
7. What validation documentation do you deliver, and at what stage is it written? The answer should be a list (requirements, functional and design specifications, risk assessment, traceability, test evidence, IQ and OQ protocols, release notes) and the word “throughout”. Documentation written after the code to satisfy a checklist is the sign of a partner who treats validation as paperwork. Our validation article describes what to expect.
8. Have you built to the EU Cyber Resilience Act, and what does that change in your process? From 11 September 2026 manufacturers of products with digital elements sold in the EU have vulnerability reporting obligations, and from 11 December 2027 the main obligations apply. A partner building instrument software should be able to describe secure development, a software bill of materials, vulnerability handling and update delivery.
9. How do you use AI in development, and how do you control it for regulated code? Generative tools are useful for prototypes and documentation and a liability when they write code nobody can explain to an inspector. Look for a policy, not a shrug. Our article on why AI cannot write your life science software sets out TotalLab’s position.
Questions about delivery
10. When will I first see working software? Weeks, not months. Iterative delivery with real outputs at each step is how scientific software gets the science right, because scientists correct what they can see. A partner who proposes a long specification phase followed by a big reveal is transferring risk to you.
11. Who will be on the project, and will they stay on it? Ask for the team by name and role, and ask how continuity is handled. Scientific context is expensive to transfer.
12. How do you handle scope, price and timeline once the work starts? The good answer is a scoped proposal with a fixed view of what will be built, a mechanism for changes, and honest reporting when something turns out harder than expected.
13. How will you test the software, and can I see a test report from a previous project? Automated tests where they make sense, documented verification against requirements everywhere, and a willingness to show you what the evidence looks like.
Questions about the long term
14. How long have your oldest products been in use, and how do you keep them running? A partner with a decade-old product still supported through operating system changes has learned what maintenance costs and how to do it. A partner with no products has not.
15. What support do you offer after delivery, and at what price? Defects, security updates, operating system compatibility, user questions and enhancement, with response times. Lifetime cost is mostly support; get it in the proposal.
16. If we part company, what do we walk away with? Source code, build instructions, documentation, the data model, and the ability to hand the software to another developer. The answer should be a clear yes.
17. How do you handle a regulatory change, for example the revised Annex 11 or a new FDA guidance? Look for evidence that the partner tracks regulation and updates its components, and a description of how customers are informed.
Questions about the commercial terms
18. Who owns the intellectual property? For a custom build, expect to own it or to hold a perpetual license; for a white-label or OEM product built on the partner’s platform, expect a license to the platform and ownership of your own branding, configuration and extensions. Either is workable; ambiguity is not.
19. What are your confidentiality arrangements, and where is our data processed? An NDA as standard, named people with access, and data that stays where you say it stays, which matters more with AI tooling in the mix.
20. Can we talk to two of your customers? One in your sector, one with a project of your size. A partner with a good record will arrange it.
| Question | What a good answer includes | Warning sign |
|---|---|---|
| 1. Who has done this science? | Named scientists with the technique and years | "Our team has deep domain expertise" |
| 2. Show shipped analysis software | A product, an accuracy method, known limitations | Screenshots only; no accuracy discussion |
| 3. Will it work on our data? | Early data, agreed acceptance criteria, testing across sample quality | "The algorithm is very robust" |
| 4. What if the science changes? | A change process with scoping and validation | "That won't happen if we specify properly" |
| 5. Where does your software run under GMP? | Named regulated customers or sectors; audits passed | Nothing regulated in the portfolio |
| 6. Map controls to Part 11 and Annex 11 | A section-by-section document | "We're compliance-ready" |
| 7. Validation documentation | A list, delivered throughout the lifecycle | Written at the end, or "we can do that if required" |
| 8. Cyber Resilience Act | Secure development, SBOM, vulnerability handling, updates | Not heard of it |
| 9. AI in development | A written policy; no unexplained code in regulated builds | "We use AI to move faster" with no controls |
| 10. First working software | Weeks | After the specification is signed off |
| 11. The team | Names, roles, continuity plan | "We'll assign resources" |
| 12. Scope and price changes | Fixed-scope proposal plus a change mechanism | Open-ended time and materials only |
| 13. Testing evidence | A real test report from a past project | "We test thoroughly" |
| 14. Oldest products still supported | A decade or more, with the maintenance story | No products of their own |
| 15. Support after delivery | Defects, security, OS changes, enhancements, response times, price | Support not in the proposal |
| 16. Exit | Source, build, documentation, data model, handover | Code stays with the developer |
| 17. Regulatory change | Regulation tracked; components updated; customers informed | "We build to the spec you give us" |
| 18. IP ownership | Clear ownership or perpetual license | Silence, or ownership retained without a license |
| 19. Confidentiality and data | NDA, named access, data residency, AI tooling controls | Data used to train tools |
| 20. References | Two customers, one in your sector | References "on request" that never arrive |
Warning signs
Some patterns predict trouble reliably enough to end the conversation.
The proposal prices the whole project before anyone has asked about the science. A partner who can quote without understanding the measurement is either guessing or planning to charge for the difference later.
The compliance answer is a list of acronyms. “We build to 21 CFR Part 11, HIPAA, GDPR, ISO 27001 and SOC 2” without a control-by-control mapping is marketing.
The demonstration is always on the partner’s data. Ask to see it run on yours before you sign.
Everything is a platform. If the answer to every requirement is a module of the partner’s product, you are buying a product, and should evaluate it as one.
The team that sells is not the team that builds. Ask to meet the engineers.
No scientific products of their own. Building and supporting a product for a decade teaches lessons that project work does not, and a partner without that history will learn them on your project.
An RFP checklist you can reuse
Paste the following into a request for proposal, and ask each bidder to answer every item in writing before any presentation.
Science: Named team members with laboratory or analytical backgrounds and their role on this project. Two examples of shipped analysis software with the method used to establish accuracy. The plan for obtaining and testing against our data, with proposed acceptance criteria.
Compliance: Regulated environments where your software runs today. A mapping of your standard components to 21 CFR Part 11 §11.10, §11.50 to §11.300 and EU Annex 11. The validation documentation set you deliver, with the stage at which each item is produced. Your approach to the EU Cyber Resilience Act. Your policy on AI-assisted development for regulated code.
Delivery: Date of first working software. The named team and a continuity plan. Your scoping, pricing and change mechanism. A sample test report from a previous project.
Long term: Your oldest supported product and how it is maintained. The support agreement: scope, response times, price. Exit terms: what we receive if the engagement ends. How you track and respond to regulatory change.
Commercial: Intellectual property terms. Confidentiality, data handling and data residency. Two customer references.
| Area | Items to request in writing | Weight for a regulated analysis project |
|---|---|---|
| Science | Named scientists; two shipped analysis examples with accuracy method; plan and acceptance criteria for our data | High |
| Compliance | Regulated customers; Part 11 and Annex 11 control mapping; validation document set and timing; CRA approach; AI policy | High |
| Delivery | First working software date; named team and continuity; scope and change mechanism; sample test report | Medium |
| Long term | Oldest supported product; support agreement; exit terms; regulatory change process | Medium |
| Commercial | IP terms; confidentiality and data residency; two references | Medium |
Score each bidder on all five groups, and weight science and compliance for a regulated analysis project.
How TotalLab answers these questions
The list above is not neutral, and it is fair to say why. TotalLab has built and sold its own analytical software for more than twenty years, so the questions about shipped products, accuracy, long-term support and regulatory change have answers that are decades long. The team is made up of PhD-educated life scientists, mathematicians and software developers. The software runs in the regulated environments of some of the largest pharmaceutical companies and has passed the audits that come with them, and the compliance components (audit trails, electronic signatures, granular permissions, image authenticity verification) exist as a product, AuditSafe, that other manufacturers integrate. Projects start with a free 30-minute discovery call, proceed to a scoped proposal, are built iteratively with working software shown early, and are validated and supported afterward. The case studies page has the projects that can be named; several more are under NDA.
Frequently asked questions
Q: What should I look for in a life science software development company?
A: Named scientists on the team, shipped analysis software whose accuracy has been established, products running in regulated environments, validation documentation produced throughout the lifecycle, early working software, long-term support, and clear intellectual property and exit terms.
Q: How do I evaluate a software vendor for 21 CFR Part 11 work?
A: Ask for a control-by-control mapping of their components to Part 11 and Annex 11, a live demonstration of the audit trail and electronic signatures, the validation documentation set, and the names of regulated customers whose audits they have supported.
Q: Should I choose a specialist scientific developer or a general agency?
A: For software whose output is a measurement or whose records will be inspected, a specialist. The cost and risk sit in the science and the compliance, and a partner who already understands them starts the project where a generalist finishes learning.
Q: What questions should be in a software development RFP for a laboratory?
A: Team and scientific background, shipped analysis examples, plan for testing on your data, regulated customers, compliance mapping, validation deliverables, Cyber Resilience Act approach, AI policy, first working software date, support terms, exit terms, IP terms and references. The checklist above is written to paste in.
Q: Why does a developer’s own product history matter?
A: Because supporting a product for a decade through operating system changes, regulatory changes and customer audits teaches what scientific software costs to keep alive. A developer with that history builds for maintenance from the start.
References
1. U.S. Food and Drug Administration. 21 CFR Part 11, Electronic Records; Electronic Signatures. eCFR. https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11
(Source for: the section numbers used in the compliance mapping.)
2. European Commission. EudraLex Volume 4, Annex 11: Computerised Systems. https://health.ec.europa.eu/medicinal-products/eudralex/eudralex-volume-4_en
(Source for: supplier assessment and validation responsibilities.)
3. European Commission. Cyber Resilience Act. https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
(Source for: entry into force 10 December 2024; reporting obligations from 11 September 2026; main obligations from 11 December 2027.)
4. ISPE. GAMP 5 Second Edition. July 2022. https://ispe.org/publications/guidance-documents/gamp-5-guide-2nd-edition
(Source for: lifecycle controls for custom software.)
5. TotalLab. About TotalLab; Custom life science software development; Case studies. https://totallab.com/about-life-science-software-development/ ; https://totallab.com/custom-life-science-software-development/ ; https://totallab.com/case-studies/
(Source for: TotalLab’s team, process and project history.)
Put the twenty questions to us
Book a free 30-minute discovery call and ask any of them. You will be talking to a scientist who writes software, and you will get answers with names, dates and documents attached.