At a tech-bio lunch during Cambridge Tech Week, one of the speakers described the apps he had built for himself. There were around twenty. He is not a coder and has no intention of marketing any of them. One was designed around the needs of a pharma business development role, drawing together late-stage pipelines, recent deals and an estimate of market size. He had not chosen the data sources himself. He asked which free databases were available, and the AI offered to connect them for him.
Life sciences organisations have seen a version of this before. A spreadsheet starts as one person's way of making a calculation easier. It proves useful, a colleague starts using it, and before long it is part of how a team works. The spreadsheet itself has barely changed. What has changed is how it is used.
AI makes that shift easier and faster. A scientist might connect a literature search to an AI model so that she no longer has to summarise papers by hand.
The speaker called tools like these "micro apps": small tools built by one person around one problem, which do not need to begin as software projects. Some will stay personal. Others will gradually become part of the workflow, often without anyone being able to say when that happened.
More people can now build
The line between people who used software and people who developed it was never perfectly clean, as the spreadsheet shows. Natural-language and no-code tools have moved it much further. Someone who understands a scientific or commercial problem can now build something around it without being a developer.
There is real value in this. The people doing the work usually know where the friction is: the information copied from one system to another every week, or the comparison that takes an afternoon when it should take ten minutes.
But the builder may understand the problem far better than the technology underneath. A tool can work well without its builder knowing how the model behaves, what changes when the model is updated, or what happens to information once it passes through an external service. While the builder is the only user, that may not matter much. Once other people rely on the result, it does.
Then comes orchestration
A micro app can also link several tools or models together, each passing its result to the next. This is usually called orchestration.
Take a researcher who searches several sources for scientific papers. The results go to an AI model, which summarises them. Another step pulls selected findings into a comparison table, and the table ends up in a portfolio discussion. There is no single "AI answer" here, only a chain.
At the lunch, someone in the audience asked the question underneath this. The tools pulled information together convincingly, but how would anyone know what was missing? Other ordinary questions become harder to answer too: which sources were actually searched, what happened to the information between steps, and whether the same workflow would give the same result next week. It might not, even if nobody has touched the application, because an underlying model or external service has been updated.
If people start relying on the result, someone may eventually need to say where it came from, retrace enough of the steps to understand what happened, and know whether sensitive information left the organisation along the way. Life sciences has asked questions like these for a long time. The difference now is how easily the workflow behind them can be assembled.
Reliance can change before the tool does
A micro app can change category without changing much technically. At first one person uses it to explore an idea. Then they use it again. A colleague asks for the output, and the results start appearing in a regular meeting. Someone connects another information source. Eventually a decision gets made on the assumption that the output will be there and is reliable enough.
The significant change has happened in the organisation around the tool.
In life sciences, a tool can also drift between different kinds of work. Something built for early exploratory research might later feed into a quality or regulatory discussion. A tool that started with public material could be connected to confidential data. An output first read as background could come to carry real weight in a decision.
The sector already treats a tool that supports a regulated activity very differently from one used informally for exploration. Micro apps make it harder to see which side of that line a tool is on, especially when it crosses gradually. What a tool is for cannot always be settled when it is first built. It may need to be looked at again as people use it differently.
Who is supposed to notice?
Here the problem becomes awkward. The technology or quality team may not know the tool exists. The person who built it knows what it does, but may not see all the ways colleagues have come to depend on it. And requiring formal approval for every small experiment would undo much of what makes these tools worth having.
What can be seen are changes in use. Has someone other than the builder started using it? Has its output become part of a recurring process or an important decision? Has a manual check been dropped because the tool is assumed to work? Would work be disrupted if it stopped, or started giving different answers?
None of this automatically means a small tool must become a formal IT system. Sometimes the right conclusion is simply: this is a useful personal tool, and it can stay one. What matters is that the reliance is visible enough for that choice to be made on purpose.
A change without a project
Large systems are easy to see. They come with budgets, owners and implementation plans. Micro apps come with none of these. No new system has arrived, yet the organisation works differently.
As AI tools get easier to build and combine, this is likely to happen more often. The harder question is who is in a position to see it while it is happening, early enough to respond without making useful experimentation needlessly difficult.
This article reflects EFEC's perspective on organisational practice and the responsible use of emerging technology in life sciences. It is intended to contribute to wider discussion and does not constitute regulatory, legal or technical advice.
Image: A phone, laptop and notebook on a desk. Photo by 2H Media on Unsplash.
