What is LIMS software development, and which labs need a custom LIMS?
LIMS software development is the design and build of a laboratory information management system: the database and screens that hold every sample, test, result, instrument and signature a testing lab produces. A custom LIMS is written around your own methods instead of forcing them into a product’s shape.
The labs that feel the need first are the ones where one report can stop a shipment or a batch release. A food lab testing spices for export. A drinking-water lab signing results for a municipal tender. A pharma quality-control unit releasing raw materials and finished batches. An environmental lab reporting stack emissions and effluent against consent conditions. A textile lab checking colour fastness, pH and restricted substances against a buyer’s list.
All of them share the same pain: sample numbers kept in a register, results in personal spreadsheets, a certificate assembled in Word, and an assessment week spent hunting for who changed a number and why. LIMS software development fixes the record-keeping, not the chemistry. It gives each sample one ID, each result one owner, each edit a reason, and each certificate a documented review.
- More than a few dozen samples a day, or several analysts sharing instruments
- Customers who ask for status and reports by email every day
- Accreditation, customer audits or regulatory inspections on the calendar
- Specifications that differ by product, grade or customer
LIMS or LIS: why a testing lab should not run on pathology software
A LIS (laboratory information system) is built around a patient, a doctor and a clinical report; a LIMS is built around a sample, a specification and a certificate of analysis. Using one for the other creates constant workarounds.
Clinical software asks for age, sex and referring doctor, applies biological reference ranges and prints a medical report. A food or pharma QC lab has none of that. It needs batch numbers, manufacturing and expiry dates, sampling plans, specification limits that change with the product grade, and pass or fail against those limits. It needs retained-sample tracking and disposal records. It often needs one sample split into sub-samples going to three departments at once.
The reverse is true as well. If you run a diagnostic lab, do not buy a LIMS designed for water testing and try to bend it into patient reports. We cover that build separately in our guide to pathology lab software, and the booking side in diagnostic centre website design.
The two do share a few building blocks: barcodes, instrument interfacing, audit trails and signed PDFs. What differs is the data model underneath, and the data model is the part that is hardest to change later. That is why the first two weeks of any LIMS software development we take on are spent on it.
How does sample chain of custody work in a custom LIMS?
Chain of custody is an unbroken, time-stamped record of who held a sample, where it was stored and what was done to it, from receipt to disposal. In a LIMS each hand-over is a scan or a click that cannot be erased later.
At receipt the front desk logs the client, sample description, quantity, container, seal condition and temperature on arrival. The LIMS prints a label with a unique ID and, for split samples, child IDs. If the seal is broken or the cold chain was lost, the receiver records it and the client is told before testing starts, not after the report goes out.
After that, custody moves with the work: issued to an analyst for preparation, moved to a refrigerator shelf, transferred to the instrument room, returned to the retention store. Each move records the person, the time and the location. When the retention period ends, disposal is logged with the method and a witness if your procedure requires one.
For environmental and legal samples where a court or regulator may read the record, we add a printable custody form with signatures at collection and receipt, so the paper and digital trails match.
- Receipt: condition, seal, temperature, quantity, photos if needed
- Label: unique ID plus child IDs for sub-samples
- Storage: fridge, freezer or shelf location with temperature log link
- Transfers: analyst to analyst, room to room, each scanned
- Retention and disposal: date, method, person, witness
How does LIMS software development handle ISO/IEC 17025 audit trails?
A proper audit trail records every creation, change and deletion of data with the user, date, time, old value, new value and reason, and it cannot be switched off by ordinary users. That is the feature assessors look for first in any LIMS.
NABL, India’s accreditation board, accredits testing and calibration laboratories against ISO/IEC 17025, as its website states. The standard expects labs to control their data and records so results can be traced and changes can be seen. It does not dictate software screens, so the way we design the trail follows your quality manual.
Many pharma QC labs also answer to US FDA expectations. The US rule on electronic records, 21 CFR 11.10(e), asks for “secure, computer-generated, time-stamped audit trails” covering entries and actions that create, modify or delete records, and says record changes “shall not obscure previously recorded information.” We build to that idea for every client, regulated or not: nothing is overwritten, every edit adds a row.
Practically, that means results are never updated in place. The LIMS stores each version, marks which is current, and forces a reason from a pick-list or free text before saving a change. Approved results lock; changing one after approval needs a re-open with its own reason and a fresh approval. Your quality manager gets a filter by sample, user or date range, and an export for the assessor.
Electronic signatures and the review–approval chain
An electronic signature in a LIMS is a deliberate act by a named user, re-entering their password, that records what they are signing and why. It is not a scanned image of a signature pasted on a PDF.
The US FDA rule 21 CFR 11.50 says signed electronic records should show the printed name of the signer, the date and time of signing, and the meaning of the signature, such as review, approval, responsibility or authorship. Section 11.300 adds that each ID and password combination must be unique to one person and reviewed periodically. We use those three items on every signature line in the LIMS and on the COA, whether or not your lab exports to the US.
A typical chain has three steps. The analyst enters and submits results. A reviewer checks calculations, instrument status and specifications, then signs as reviewed. An authorised signatory, named in your scope, signs as approved and the certificate is released. The LIMS enforces that the same person cannot enter and approve the same result, and it keeps a list of who is authorised to sign for which tests.
What we build
Signature prompts with password re-entry, a meaning pick-list, signatory authorisation by test, and signature manifests printed on the report.
What stays with your lab
Deciding who may sign, training records, and your own procedures for lost credentials and periodic access reviews.
Instrument calibration logs and equipment status
The equipment module keeps a register of every instrument with its calibration certificate, next due date and intermediate checks, and it blocks an out-of-date instrument from being used in a test. A spreadsheet can remind; only a LIMS can refuse.
For each balance, pH meter, oven, incubator, pipette, spectrophotometer or chromatograph we record the identification number, location, range, the external calibration agency and certificate number, the date and the due date. Daily or weekly checks, such as a balance check with standard weights or a pH buffer check, are entered by the analyst in a few taps, with pass or fail against tolerances you set.
When an analyst starts a test run, the LIMS lists only instruments that are in calibration and have passed their latest check. If a check fails, the instrument is tagged out of service and the quality manager is alerted. If a calibration certificate later shows the instrument was out of tolerance, the LIMS can list every result produced on it since the previous good calibration, which is the first question in any impact assessment.
Reference standards, reagents and cultures follow the same pattern: lot, opening date, expiry, and a block on expired material.
LIMS software development for food, water, pharma QC, environmental and textile labs
Every matrix brings its own specification sources and report expectations, so LIMS software development starts by listing them. The same engine can serve all five; the master data is what changes.
Food and spices
Product categories, parameters such as moisture, aflatoxins or pesticide residues, and limits that can differ between domestic sale and each export market. Sub-sampling for microbiology and chemistry is common.
Drinking and process water
A fixed parameter panel per sample type, acceptable and permissible limits, field data like sampling point and residual chlorine, and bulk reporting for tenders or housing societies.
Pharma QC
Raw material, in-process and finished-product tests against monographs, stability pulls at set time points, retained samples, and out-of-specification investigations linked to the batch.
Environmental
Ambient air, stack, effluent, soil and noise, with site and GPS data, sampling equipment records, and results compared with the limits in the client’s consent conditions.
Textile and leather
Colour fastness ratings, pH, formaldehyde and restricted substances against a brand’s list, with photos of swatches and buyer-specific report templates.
A lab working across several matrices does not need several systems. It needs a flexible test master, specification sets that can be attached to a product or a customer, and report templates chosen by client.
How is a certificate of analysis generated in a custom LIMS?
The LIMS builds the COA from the approved results, the specification that applied, and the signature records, so nobody types anything into the certificate. If a number on the COA does not match the database, something has gone wrong, and the design makes that impossible.
A COA template holds your letterhead, accreditation details where you are allowed to show them, client and sample details, dates of receipt and testing, each parameter with its method reference, unit, result, limit and pass or fail, remarks, and the reviewer and approver signature manifests. The template can differ by client, so a buyer who wants its own format gets it without manual editing.
Release happens only after approval. The PDF gets a unique report number and a QR code that opens a read-only verification page, which stops edited copies circulating. If a report must be amended, the LIMS issues a new version marked as amended, keeps the original, and records why.
Clients can then download reports from a portal or receive a link by email or WhatsApp. For busy labs we add bulk COA generation per job and a monthly statement for account customers.
Getting results from instruments into the LIMS without retyping
Most testing-lab instruments can export a file, and parsing that file is usually the cheapest reliable way to stop transcription errors. Direct real-time links are possible for some instruments but cost more.
Balances and pH meters often print to a serial port or export CSV. Spectrophotometers, AAS and ICP software, and chromatography data systems export result tables. We write a small parser for each format: the analyst uploads or drops the export, the LIMS matches rows to sample IDs, and results are posted with the file kept as raw data. Each instrument format is its own line on the quote.
We are honest about the limits. The chromatography data system remains the home of the raw chromatograms and its own audit trail; the LIMS stores the reported values and a link to the run. We do not modify instrument software, and we do not supply cables or converters. Where an instrument has no export at all, the LIMS provides double-entry or second-person verification for manual results.
For scanned paper worksheets from the field, OCR can help, but it still needs a human check. See our note on OCR software development before you plan on it.
How much does LIMS software development cost in India?
Custom LIMS software development with our team starts at ₹60,000 (about US$900) for a first release covering sample login, custody, tests, results, audit trail, approval and one COA. What moves the price is scope, not the word “LIMS”.
The biggest drivers are the number of matrices and specification sets, how many instrument formats we parse, whether you need a full equipment and calibration module, a client portal, stability studies or out-of-specification workflows, and how much validation paperwork we write with you. Migrating years of spreadsheet data adds time, because it always needs cleaning.
Quotes from other developers and product vendors vary widely. The gap usually comes from licensing models, how much configuration is done by the vendor, and whether validation support is included. Compare what each quote actually delivers, line by line, rather than the headline figure.
Your running costs after launch are cloud hosting, paid directly to the provider, and optional maintenance from ₹8,000/mo once the two free months end. There are no per-user fees on the code, so adding a new analyst does not change your bill.
How long does LIMS software development take?
A first working release takes 6–12 weeks, delivered in phases so your analysts start using the core while the rest is built. A lab that waits for everything at once usually waits longer.
Weeks one and two go to discovery: we sit (on video) with your front desk, an analyst, the reviewer and the quality manager, collect your worksheets, COA samples and SOPs, and draw the sample lifecycle. You approve a written scope and data model. Weeks three to six build sample login, custody, test master, result entry and the audit trail, shown to you every week on a test server.
Weeks seven to ten add review and approval, e-signatures, the COA builder and the equipment module. The last stretch covers instrument parsers, migration of your master data, user acceptance testing with real past samples, and training. A parallel run, where the lab keeps its old process for a couple of weeks alongside the LIMS, is the safest way to go live.
What slows projects down is almost never code. It is waiting for specification lists, sample report formats, instrument export files, or a decision on who signs what. Having those ready shortens the job more than anything we can do.
Licensed LIMS or custom LIMS software development: a decision rule
Choose a licensed LIMS when your methods and reports are standard and the vendor already serves labs like yours; choose custom LIMS software development when you would spend the licence fee mostly on workarounds.
Licensed products bring years of features and, for some, validation packs. Their costs are per user or site, plus implementation and yearly support, and changes follow the vendor’s roadmap. They suit a lab that can adapt its forms to the product.
Custom builds suit labs with unusual combinations: a textile lab with a dozen buyer templates, a contract lab serving both food and water clients, a QC unit whose stability protocol does not fit anyone’s module, or a group with several branches wanting one database. You own the code, pay no per-user fees, and changes are quoted and added when you need them.
There is a middle path: start with a small custom LIMS for sample login, custody and COAs, then decide on the rest. Our comparison of ready-made and custom software goes deeper.
- Standard methods, one site, few clients: evaluate licensed products first
- Many customer-specific formats or matrices: custom usually wins
- No IT staff at all: insist on cloud hosting and clear support terms either way
Validation and data integrity: what the lab still owns
Software can support data integrity, but validation is the lab’s responsibility: you decide the intended use, the risks and whether the system is fit for purpose. We help by writing the evidence alongside the code.
For each requirement in the approved scope we write test scripts with expected results, run them on the test server, and hand you a traceability matrix linking requirement to test to outcome. You or your consultant then run the acceptance tests in your environment and sign them. For pharma QC labs that follow a computer system validation approach, those documents feed your own protocols.
Data integrity is also about habits. Unique logins for every person, no shared analyst accounts, automatic logout, role-based access so an analyst cannot approve, backups tested by restoring them, and time taken from a trusted server clock rather than a PC. We build those controls in; your SOPs and training make them stick.
We do not certify, accredit or sign off your system, and we do not give regulatory advice. We give you software that behaves predictably and paperwork that shows how it was tested.
Technology choices for a lab LIMS that must last
We build a LIMS as a web application on a relational database, hosted in your cloud account, because audit trails, specifications and results are relational data that must stay consistent for years.
A typical stack is a PostgreSQL database, a server layer in Node.js or Python, and a browser front end that works on lab PCs and tablets at the bench. Barcode printing uses standard thermal label printers; scanning uses ordinary USB scanners that type into the browser. PDFs are generated on the server from locked templates.
Hosting runs in a cloud region in India by default, with daily backups, point-in-time recovery, encrypted storage and HTTPS. If your policy requires servers on your own premises, we can deploy there, provided your IT team maintains the machine. Another of us on our team handles the AWS and database side, including monitoring and restore drills.
We avoid exotic frameworks. A LIMS outlives several developers, so the next person who opens the code, whether us or someone you hire, should recognise everything in it. For broader background on this kind of build, see our page on web application development.
Who owns the LIMS, the data and the code after handover?
You do. The source code sits in a repository under your account, the database lives in your cloud account, and the admin credentials are yours from the first day. We work inside your accounts rather than holding anything back.
At handover you receive the code, deployment notes, the data model diagram, the validation test pack, and a short admin guide covering users, roles, specifications, templates and backups. If you later hire in-house developers or another freelancer, they start from the same documents we use.
The first two months after launch include free maintenance: bug fixes, small adjustments found in daily use, and help during your first assessment or audit with the system. After that, maintenance is optional from ₹8,000/mo, or you can take it in-house. New modules, such as a stability module or a client portal, are quoted separately when you want them.
Contract terms, confidentiality and anything beyond this are agreed in your written quote; our terms page has the general conditions.
Red flags and a checklist before you commission LIMS software development
The biggest red flag is a developer who starts building screens before understanding your sample lifecycle. The second is anyone who promises that their software will get you accredited. Neither is a good sign for a system you will live with for years.
Other warning signs: results stored in a way that can be edited without trace, shared logins suggested “for convenience”, code or database hosted in the developer’s account, no test server, no written scope, or a demo that never uses your own report format. Ask to see an audit trail export on day one of any demo.
Before you ask anyone for a quote, gather the following. It turns a vague conversation into an accurate, itemised price.
- Three recent COAs or test reports, one per main client type
- Your list of matrices, tests and methods, with specification sources
- Current worksheets or Excel files analysts use at the bench
- Instrument list with make, model and export options
- Who reviews and who approves, per test or department
- Sample volume per day and number of users
- Retention periods and disposal rules
Worked example: a hypothetical food and water lab in Vadodara
Say a mid-sized lab in Vadodara tests drinking water for housing societies and spices for exporters, with nine analysts, one reviewer per department and two authorised signatories. This is an illustration of scoping, not a real client.
Their pain points are familiar. Water samples arrive in bulk from one society with a dozen sampling points; spice samples come with export-market limits that differ by buyer. COAs are made in Word and a missed decimal point once went out to a client. Balance checks sit in a notebook.
Phase one of their LIMS software development would cover sample login with bulk registration, custody from receipt to retention, a water parameter panel with acceptable and permissible limits, spice specification sets by market, result entry with audit trail, review and approval, and two COA templates. Phase two would add the equipment register with balance and pH checks that block failed instruments, a parser for their spectrophotometer exports, and a client portal with WhatsApp report alerts.
Priced from ₹60,000 for phase one, with phase two quoted as separate lines, the lab would run both systems in parallel for two weeks before retiring the Word templates. Every figure above except our starting price is hypothetical.