Most lab automation software is not badly built because the people are bad. It is badly built because it starts from the wrong question.
Too many systems begin with: "How do we automate this workflow?"
The better question is: "What are the reusable primitives underneath this workflow?"
That difference is what separates project engineering from real product engineering.
Most Lab Automation Software Is Built from the Wrong Direction
One of the biggest problems in lab automation is that too much of it is built from the wrong perspective.
It usually starts with the project. What assay are you running? What instrument do you need? What workflow are you trying to automate? What robot are you using? What data needs to come out at the end?
Those questions matter. Of course they do. The science matters, the workflow matters, the instruments matter, and the outcome matters. But if the architecture of the software starts there, then the first mistake has already been made.
You are no longer building a platform. You are building a solution for one workflow.
Then the next customer comes along with a slightly different process, a different instrument, a different plate type, a different exception, a different reporting requirement, or a different way their scientists prefer to work.
So the system gets patched. Then patched again. Then a special rule is added. Then a special script. Then a custom driver. Then a workaround that was meant to be temporary but somehow becomes part of the product for the next five years.
Eventually, what you have is not a platform. It is a collection of project-specific decisions pretending to be a product.
This is where a lot of lab automation has gone wrong. It has been treated as project engineering rather than product engineering.
Listening for Behaviours
At LAB DONKEY, we look at this differently.
When we speak with a potential client, different people on our team are listening for different things. Some are focused on the science. They are listening to the workflow, the instruments, the labware, the process constraints, the pain points, and the outcome the customer needs.
I am listening for something else.
I am listening for behaviours.
What action does the software need to support? What decision does the system need to make? What part of this workflow is genuinely unique, and what part is just another expression of a pattern we already understand? What are they asking for that reveals a missing capability in the platform? What do we need to build so that this problem is solved not just for this customer, but for every future customer with a similar class of problem?
That distinction matters.
The old way is to build around the customer's current workflow. The better way is to understand the workflow, then extract the reusable primitives underneath it.
This Is How Serious Software Is Built
The team behind Microsoft Word or Google Docs is not going out to customers and asking, "Are you writing a contract?", "Are you writing a business plan?", "Are you writing a scientific paper?", or "Are you writing a resignation letter?"
Those are not the fundamental product questions.
The fundamental question is: what does a document need to do?
A document needs structure. It needs formatting. It needs collaboration. It needs comments. It needs version history. It needs permissions. It needs templates. It needs export options. It needs extensions.
Once those primitives exist, users can create almost anything on top of them.
Lab automation needs the same shift.
The question should not be, "How do we hard-code this one workflow?"
The better questions are: what is a workflow? What is an instrument? What is a method? What is labware? What is a workcell? What is a transfer? What is an exception? What is a recovery path? What is the minimum abstraction that lets us support hundreds of workflows without rebuilding the product every time?
That is the level where lab automation software needs to be designed.
Custom Rules Sit on Top of the Platform
There will always be customer-specific rules. Labs are not identical. Instruments behave differently. Scientists have preferences. Processes have constraints. Reality is messy.
But custom rules should sit on top of a strong platform. They should not become the platform.
This is the trap too many systems fall into. Every customer requirement becomes a special case. Every special case becomes a feature. Every feature becomes a dependency. Over time, the product becomes harder to change, harder to maintain, harder to deploy, and harder to explain.
That is not inevitable. It is a consequence of poor product thinking.
At Lab Donkey, we are building one consistent way to describe a lab, one consistent way to model a workcell, one consistent way to build workflows, and one consistent way to handle the rules and exceptions that make each lab different.
That does not mean every lab becomes the same. It means the underlying software model is strong enough to handle difference without collapsing into chaos.
This is the difference between building software that scales and building software that slowly drowns in its own customisations.
The future of lab automation will not be won by whoever can build the most one-off demos. It will be won by whoever can turn lab complexity into reusable software primitives.
That is the game we are playing at Lab Donkey.