Why labs end up building a customer app

A genetics lab is built to do one hard thing well: take a sample and return a correct result. The systems inside it are shaped around that job, from accessioning through to the report that goes out. Then the report goes out, and a different kind of work starts arriving.

The requests that arrive after the result

None of these are testing problems, and all of them land on the lab.

• Re-send the report from four years ago, because the animal has been sold.
• Show every result for this animal, across the panels it has had over its life.
• Show every result for these forty animals, because the customer runs a program.
• Confirm the animal on this report is the animal in front of me.
• Explain what this result means for a mating.
• Send this result to a registry, or to a buyer, in a form they will accept.

A lab system is a poor place to answer these, because it is organised around samples and batches. The customer is asking about an animal, over years, across panels, and often across labs.

How it turns into a product

The first answer is usually a portal. Customers can log in and download their reports, which solves re-sending.

Then the requests keep coming. The portal needs accounts, and accounts need roles, because a trainer and an owner are not the same person. It needs the animal as a first-class thing rather than a column on a sample, so results can be grouped over time. It needs identifiers and a way to correct them. It needs sharing, which needs permissions. Somewhere in there it needs pedigree, because that is what customers ask the results about.

Each step is a reasonable answer to a real request. Together they are a software product, with a roadmap, a support burden, and a second system of record that drifts from the lab system over time. It competes for the engineering attention that could be going into throughput, new panels, and turnaround.

The part a lab portal structurally cannot solve

A portal holds your results. The customer’s animal has results from other labs too: a panel from one provider, a parentage verification from another, a health screening from a third, plus registry papers and veterinary records.

No single lab’s portal can be the animal’s record, because no single lab has all of it. The customer ends up back in a spreadsheet, retyping results from several portals into one place, which is where the lab’s name and the test’s exact identity fall off. Our guide on where your report goes after you issue it follows what happens next.

That is a structural limit, not a question of building the portal better.

Where an integration point fits instead

The alternative is to let the record live somewhere neutral, keyed to the animal rather than to the lab, and to connect to it.

For a lab, that means the result arrives with your lab named as its source and your original report attached, sits alongside other labs’ results without either overwriting the other, and stays usable in the decisions your customers make afterwards. Owners get the history and the sharing they were asking you for. You keep issuing results, and you stop owning a product that was never the point.

AnimalTrace does not run your lab, replace your lab system, re-interpret a result, or certify anything. That boundary is what makes it usable as an integration point rather than as a competitor for the customer relationship.

What connecting involves

Customers can already bring your reports in themselves, so there is a working path before any integration exists. If you would rather send results directly, that happens in a guided setup: tell us how results leave your system today, whether as files, through a customer portal, or by API, and we work out the connection with you. Nothing inside the lab has to change, and it is worth starting with one result flow rather than all of them.

Talk to us about results, or read how AnimalTrace works with labs.