Custom Lab Software vs Off the Shelf: How to Choose
Most labs need both. The real question is not whether to build or buy - it is knowing which layer your Laboratory Information Management System (LIMS) should own and which layers it cannot serve well. Getting that boundary wrong costs accreditation time, validation effort, and years of painful workarounds. This guide applies four concrete decision criteria so your lab can reach a position it can defend to auditors, accreditation bodies, and its own QA team.
If you are still weighing whether you need a new LIMS at all versus a workflow improvement, the new LIMS or better workflow guide covers LIMS product selection separately - that question sits outside this article's scope.
What "build vs buy" actually means in a lab context
Defining the terms
Custom lab software is built specifically for your laboratory's workflows, data structures, and business rules. Nothing is pre-packaged: the scope, the architecture, and the validation lifecycle are yours to own. Off-the-shelf lab software - most commonly a commercial LIMS - arrives with predefined workflows, vendor-managed updates, and often a vendor-supplied validation package. You configure it to your lab; you do not rebuild it.
The hybrid model sits between these two positions, and it is not a compromise. It is an architecture: keep the validated LIMS for the work it does well, and build purpose-specific software for the layers surrounding it. Most labs that have operated long enough to outgrow their initial setup have landed here, deliberately or not.
Why the lab context changes the decision
A generic business choosing between off-the-shelf and custom software is weighing speed against flexibility. A regulated laboratory is weighing all of that plus validation burden, accreditation risk, and audit defensibility - and those factors dominate.
Under ISO 17025 (testing and calibration laboratories) and ISO 15189 (medical laboratories), any software that affects result integrity must be validated before use. That validation must be documented, controlled, and repeatable. Choosing your software architecture therefore determines who owns that obligation - and for how long.
Configuration vs customisation is the critical distinction here. Configuration means adjusting the software within the parameters the vendor has already validated: enabling fields, setting workflow steps, defining result ranges. Customisation means writing new code or modifying the product beyond its validated envelope. Configuration keeps you inside the vendor's Installation Qualification / Operational Qualification / Performance Qualification (IQ/OQ/PQ) package. Customisation steps outside it, and the lab takes on the validation burden for whatever it changed.
Configuration stays within the vendor's validated envelope. Customisation steps outside it - and the lab takes on the validation burden.
Vendor lock-in carries a sharper edge in a regulated lab than in a typical software business. Switching a validated LIMS is not just a commercial decision: it triggers revalidation of the replacement system and may require re-accreditation activities. That switching cost is real and largely invisible in upfront cost comparisons. The State of Lab Digitization 2026 report found that labs consistently underestimate this cost when first evaluating software options.
Where off-the-shelf lab software wins
Core testing workflow management
Commercial LIMS products exist to manage sample registration, test execution, result entry, chain-of-custody, and audit trail. They have been built, tested, and validated for exactly these workflows across thousands of lab deployments. Rebuilding that capability in custom code is rarely justified - you would spend years reproducing what LIMS vendors have already spent years perfecting, and you would own the validation burden for every line of it.
Accreditation-aligned defaults
Good commercial LIMS products are designed with ISO 17025 and ISO 15189 requirements in mind. Audit trails, result traceability, user access controls, and electronic signature workflows are built in rather than bolted on. Vendor-supplied IQ/OQ/PQ documentation reduces the lab's validation effort significantly - the vendor has already assembled the evidence; the lab reviews and approves it rather than generating it from scratch.
For labs operating under IVDR (In Vitro Diagnostic Regulation), the IVDR software compliance obligations add another layer of documentation and risk assessment that a compliant commercial platform already accounts for.
Speed to operational readiness
When your accreditation deadline is fixed and your go-live date is not negotiable, a configurable LIMS wins on time alone. Configuration takes weeks; custom development takes months. That gap matters when an assessor's visit is already in the calendar.
Ongoing vendor support and regulatory updates
Regulatory requirements change. A commercial LIMS vendor absorbs those changes into product updates, releasing revised validation documentation alongside new features. A custom-built system requires the lab - or its development partner - to track regulatory changes independently and implement updates at its own cost and risk.
Off-the-shelf is likely the right choice for core testing workflows when:
- Your workflows map closely to the LIMS's default sample-to-result process
- You need to reach operational readiness within a fixed accreditation timeline
- You want vendor-supplied IQ/OQ/PQ documentation to reduce your validation effort
- Your integration requirements are limited to what the LIMS supports natively
- Your reporting needs are met by the LIMS's built-in report templates
- Regulatory change management is a burden you want shared with a vendor
Where custom lab software wins
Sample intake and customer-facing request workflows
Most commercial LIMS products do not include a customer-facing portal or an online test-request form. Sample intake in many labs still runs on email, phone, and PDF forms - which means manual re-keying into the LIMS at the point of receipt. Custom intake software changes that: it enforces business rules before a sample even arrives, pre-validates submission data, and passes clean, structured records directly to the LIMS. The online lab test request form guide covers how to build this layer without disrupting the core LIMS workflow.
Custom reporting and certificate delivery
Standard LIMS report templates are often too rigid for branded, client-specific certificate formats. When a lab needs to deliver certificates in a specific layout, with client-specific reference ranges, or with eIDAS-qualified electronic seals for legal recognition across EU member states, that requires custom implementation. An eIDAS-sealed certificate portal - where clients log in to retrieve tamper-evident, qualified-signed test certificates - cannot be configured from within a LIMS; it must be built. The technical requirements for qualified seals in a lab context are covered in depth in our qualified electronic seal guide.
Integrations the LIMS cannot handle natively
Instrument middleware, ERP systems, billing platforms, national health registries, and third-party quality management tools rarely connect to a LIMS out of the box. When those integration gaps force staff to re-key data between systems, the error rate rises and the audit trail breaks. Custom middleware or integration layers pay for themselves quickly in those situations - and they carry a narrower, more manageable validation scope than a full custom LIMS build. See why lab integrations fail for the most common failure patterns and how to avoid them.
Workflow automation outside the LIMS boundary
Deviation notifications, CAPA triggers, automated dispatch to external systems, and cross-system escalation workflows are difficult to implement inside a LIMS without deep customisation. Custom automation layers can bridge these gaps without touching the LIMS's validated core. The lab workflow automation guide covers what to automate first and how to scope automation projects that remain validation-compliant.
Custom development is likely justified when:
- Sample intake, submission, and customer communication happen outside the LIMS
- Certificate formats are client-specific or require eIDAS-qualified electronic signatures
- Key systems (ERP, instruments, billing, national registries) have no native LIMS connector
- Workflow automation crosses system boundaries in ways the LIMS cannot support
- Reducing manual data entry is a documented patient safety or data integrity objective
The hybrid model: LIMS for core testing, custom for everything around it
What the hybrid model looks like in practice
The hybrid model is not about choosing two tools at random. It follows the LIMS validation envelope as a natural boundary: everything inside that envelope stays in the LIMS; everything outside it becomes a candidate for custom development.
Here is how that maps across a typical regulated lab's workflow layers:
| Workflow layer | Best owned by LIMS | Best owned by custom software |
|---|---|---|
| Sample intake / test requests | ✗ | ✓ Customer portal, submission forms |
| Sample registration | ✓ | ✗ |
| Test execution and result entry | ✓ | ✗ |
| Result review and approval | ✓ | ✗ |
| Audit trail and chain of custody | ✓ | ✗ |
| Standard report generation | ✓ | ✗ |
| Branded / client-specific certificates | ✗ | ✓ Custom certificate portal |
| eIDAS-sealed certificate delivery | ✗ | ✓ |
| Instrument integration / middleware | Partial (native connectors) | ✓ When native connectors unavailable |
| ERP / billing / registry integration | ✗ | ✓ |
| Cross-system workflow automation | ✗ | ✓ |
| CAPA triggers and deviation routing | Partial | ✓ |
Connecting instruments to the LIMS is its own discipline - the lab middleware integration guide explains the patterns that keep those connections stable and validation-compliant.
Why this is the most common outcome we see at Sandorian
Across the lab projects Sandorian has delivered, two failure modes appear repeatedly. Labs that tried to customise their LIMS deeply ended up with fragile, poorly documented configurations that only one or two people fully understood - and that became nearly impossible to validate cleanly. Labs that built everything custom from scratch spent enormous effort rebuilding capabilities the LIMS already provided, then struggled to maintain a coherent audit trail across two parallel systems.
The hybrid boundary is not a compromise position. It is the engineered outcome that protects the LIMS validation investment while giving the lab the flexibility to build exactly what commercial products cannot provide. For more on integrating custom software with your LIMS, including the integration patterns Sandorian uses in production environments, that guide covers the implementation side in detail.
Four decision criteria to apply before you choose
Let's break it down. Apply each criterion directly to your lab's situation before committing to a path.
1. Workflow fit: does the tool support your process, or reshape it?
If adopting a LIMS requires you to change accredited workflows to fit the software, the compliance risk is real. Count the documented SOPs that would need revision. If that number is high, the "fast" off-the-shelf option may not be fast once you account for revalidation and SOP change control.
2. Compliance scope and validation effort: who owns validation?
Does the vendor supply IQ/OQ/PQ documentation? How deep does your planned configuration go - and does any of it cross into customisation? The ISO 17025 software requirements and LIMS validation guide explains what the validation obligation looks like in practice and how the build vs buy lab software choice affects it.
3. Integration complexity: how many systems must connect, and how?
List every system the new software must talk to: instruments, ERP, billing, national registries, customer portals. For each connection, ask whether the LIMS supports it natively or whether custom middleware is required. High integration complexity with no native connectors is a strong signal that custom or hybrid development will be necessary regardless of which core platform you choose.
4. Total cost of ownership, including the cost of change:
Licence cost versus build cost is only the opening move. Full ownership cost includes validation effort (and who carries it), training, annual licence fees, ongoing maintenance, and - critically - revalidation cost if you ever need to switch. Specific cost figures and pricing ranges are covered in a separate guide on what lab software costs; use that guide to put numbers against each of these categories for your own situation.
Decision matrix:
| Workflow fit | Integration complexity | Likely best path |
|---|---|---|
| High (tool fits process well) | Low (native connectors available) | Off-the-shelf LIMS |
| High (tool fits process well) | High (custom middleware needed) | LIMS + custom integration layer |
| Low (significant SOP changes needed) | Low | Reconfigure LIMS or reassess vendor |
| Low (significant SOP changes needed) | High | Hybrid model or custom-first |
Warning signs you are choosing the wrong path
If your lab recognises more than two of the following, the architecture needs attention - not just a new feature request.
- Staff re-key sample data, results, or client information between two or more systems as part of their normal workflow
- Test certificates or reports are assembled manually in Excel or Word outside the LIMS before being sent to clients
- Sample intake runs on email, PDF attachments, or phone calls, with no structured digital submission
- LIMS configuration has grown so complex that only one person in the lab understands how it is set up
- Meeting a new accreditation requirement means waiting for a vendor contract change rather than configuring the system yourself
- Custom-built tools in use at the lab have no documented validation protocol, no test record, and no change control process
Reducing manual data entry - one of the clearest early signals of architectural friction - is covered in practical terms in the manual data entry in the lab guide.
How to reach a decision your lab can defend
Labs are accountable to accreditation bodies, regulatory authorities, and auditors. A software decision made on gut feeling or vendor enthusiasm is not defensible. One made on documented criteria, with assessed alternatives and a written rationale, is.
Here are the steps that make a software decision audit-ready:
- Document the decision rationale. Record which criteria you applied, what alternatives you assessed, and why you chose the path you did. This is not bureaucracy - it is evidence that the decision was controlled and deliberate.
- Involve QA from the start. Not after the contract is signed. QA leads understand the validation implications of software choices in ways that IT and operations teams often do not. Getting them into the conversation early avoids expensive reversals later.
- Run a fit assessment before committing. Map your documented workflows against the tool's capabilities. Identify gaps. Classify each gap as configurable, customisable (and therefore your validation burden), or requiring custom development. This is the practical application of the four criteria above.
- Choose the hybrid model deliberately, not by accident. The hybrid outcome is likely the right answer for most established regulated labs. But it should be an architectural decision - documented, scoped, and planned - not something you stumble into because the LIMS could not do everything you needed.
For labs that want their software decision to hold up under audit, the audit-ready lab software guide covers exactly what auditors expect to see in a compliant software environment.
At Sandorian, we apply these four criteria in a structured fit assessment call with your lab's engineering and QA leads. We map your workflows, identify where the LIMS boundary should sit, and tell you plainly which layers are candidates for custom development. If you are weighing this decision now, that is the most useful next step - book a fit assessment with our team through the custom software for laboratories page, or learn more about working with us as a software engineering partner for regulated labs.
Frequently asked questions
What is the difference between configuring a LIMS and customising it?
Configuration means adjusting the LIMS within the parameters the vendor has already validated - enabling fields, defining workflow steps, setting up user roles and result ranges. Customisation means writing new code or modifying the product beyond its documented, validated scope. Configuration keeps the lab inside the vendor's IQ/OQ/PQ envelope. Customisation steps outside it, transferring the validation burden to the lab.
Does building custom lab software affect my ISO 17025 accreditation?
It affects your validation obligations, which in turn affect your accreditation readiness. Under ISO 17025, software that influences result integrity must be validated before use. When you build custom software, your lab - or your development partner - owns the entire validation lifecycle: the test protocols, the evidence, the change control, and the ongoing maintenance. This is manageable, but it must be planned and documented. The ISO 17025 software requirements guide explains what that obligation looks like in practice.
What does the hybrid model mean for a testing or calibration lab?
It means keeping your validated LIMS for sample registration, test execution, result management, and audit trail - the workflows it was built and validated to handle - while building custom software for the surrounding layers: sample intake, customer-facing portals, certificate delivery, instrument integrations, and cross-system automation. The boundary follows the LIMS's validation envelope. Everything inside stays in the LIMS; everything outside is a candidate for custom development.
When should a lab NOT build custom software?
When the LIMS already supports the workflow through configuration rather than code. When the lab lacks a development partner with regulated software experience and cannot own the resulting validation lifecycle. When the accreditation timeline is too tight to absorb a custom build. And when the gap being addressed is a process problem, not a software problem - no custom tool fixes a workflow that is not yet documented or controlled.
What is vendor lock-in and why does it matter more in a regulated lab?
Vendor lock-in is the dependency that develops when switching software becomes prohibitively expensive. In a regulated lab, that cost is not just commercial - it includes revalidating the replacement system, updating all SOPs that reference the old system, and potentially demonstrating continued compliance to your accreditation body during the transition. This makes the initial vendor selection far more consequential than it appears, and it makes the hybrid model attractive: custom peripheral layers can be replaced or evolved without touching the validated LIMS core.
Can custom software integrate with an existing LIMS?
Yes - and this is the most common starting point for labs adopting the hybrid model. Custom software connects to the LIMS through its API, database connectors, or middleware layers, depending on what the LIMS vendor supports. The integration must be validated in the same way as any other software change affecting result integrity. See integrating custom software with your LIMS for the patterns that make this work reliably.
How do I know if my current lab software is failing us?
The clearest signal is systematic workarounds: staff re-keying data between systems, reports assembled manually outside the LIMS, sample intake running through email or paper, or one-person dependency on a complex configuration no one else understands. If any of these describe your lab's day-to-day, the architecture is working against you - not with you.
Sources
Let's talk
We build the systems that power your business. Let us know how we can help.
Book a 30-min Call