Before You Build

Decide whether to build it, before you build it.

The de-risking method for health AI and technology investments.

We apply it through an evidence phase: fixed fee, eight to twelve weeks. At the end you know whether to build it, and you have the evidence to show why.

Book a conversation

The problem

The expensive questions get asked last.

Most health AI investment decisions are made on the strength of a business case, and the business case is written before anyone has seen the thing work. The assumptions inside it stay untested until the build is underway and the budget is committed.

By then the questions that mattered most are the expensive ones to answer. Will the people it is built for actually use it. Does it fit the workflow it has to live inside. Is there a commercial model that anyone would sign. Does it stay clear of the regulatory boundary you thought it did.

An evidence phase moves those questions to the front, where they are cheap.

What it is

Eight to twelve weeks, a fixed fee, and a defined end point.

You are not buying a system, and you are not starting something that becomes difficult to stop. You are buying the evidence and the recommendation you need to make the next decision properly.

It ends with one of three answers. Go ahead, rework it, or stop. Where the evidence supports proceeding, the recommended route may be to build, buy, partner, integrate, or test the proposition through a limited pilot. Whichever it is, you will be able to explain the reasoning to the people holding the budget.

Where this applies

Not only for AI models.

The common factor is not whether something uses AI. It is a meaningful investment decision resting on assumptions nobody has tested yet.

Conversational AI and AI agents

Clinical decision support

Patient engagement and coaching products

Risk stratification and prediction tools

Workflow automation

Digital therapeutics

Remote monitoring

Data enabled care models

Products combining AI with human delivered care

What it costs

Quoted for the decision, not from a price list.

Every evidence phase is quoted individually, because what would actually be useful varies far more than the format does. The cost moves with the complexity of what you are proposing, how many workstreams run alongside each other, the specialist skills it calls for, how long it needs to run, and whether it stays on synthetic data or has to work near real patient data and the medical device boundary.

Whatever the number, it is agreed and fixed before anything starts. There is no open-ended meter running.

We quote after a conversation rather than before one. That conversation is most useful when you already know what you need to decide and have a budget to investigate it. If you are not there yet, it is usually worth waiting until you are.

What you get

Shaped around the decision you have to make.

There is no fixed deliverables list, because the useful work depends on what is least certain. An evidence phase usually produces some combination of the following, weighted towards whichever of them your decision actually turns on.

A working model, where it would help

Not every decision needs software to resolve it, so this is included when it earns its place. Where it does, it is built to test the riskiest part of the proposition rather than to become the first version of the production system.

Software that runs on synthetic data and brings the idea to life. Not a mockup and not a video, but something people can use and react to.

It sits between a prototype and a minimum viable product, and it can be built to anywhere on that line depending on what the decision needs. That makes it useful for gathering market feedback, not only for testing the idea inside your own organisation.

The decision logic

How the inputs you have come together into something a clinician or a health coach could act on. This is usually the part that is hardest to specify, and the part that decides whether the rest of the idea holds up.

Evidence from the people who would have to adopt it

Structured conversations with the providers, clinicians and partner organisations whose decision it would ultimately be. Whether they would use it, how it fits what they already do, and what commercial model would carry it.

An early view of the regulatory and governance position

An assessment of the likely regulatory, clinical safety, information governance and assurance considerations that follow from the intended purpose you are proposing. It identifies the assumptions the position depends on, and where specialist legal, regulatory or conformity assessment advice will be needed.

The aim is not a definitive classification in the abstract. It is to know the likely position early, while product choices can still be made around it.

A written recommendation

A position on whether to go ahead, rework it or stop, with the evidence behind it. Written to be read by people who were not in the room.

Where relevant, the assessment is informed by applicable MHRA guidance, expectations affecting CQC regulated providers, recognised Good Machine Learning Practice principles, and standards such as ISO/IEC 42001, which is an AI management system standard rather than a product safety one. Which of these apply depends on the product, its intended purpose, the organisation and the route to market. More on that in safety and governance.

What we bring

The hard part is the logic, not the model.

Technology does not create value. People changing what they do creates value. Technology creates value only when it changes behaviour.

A health technology only produces an outcome by travelling a chain, and the chain is only as strong as its weakest link.

Need
Something is wrong, or could be better
Prediction
The system detects or forecasts it
Decision
What this means, and what should happen
Action
Someone does something differently
Outcome
The thing you actually wanted

Most investment and attention go into the second step. Most of the value is decided in the third and fourth.

Most health AI work stops at prediction. It can tell you who is likely to struggle. It rarely tells you what to do about it.

The difficult work is deciding what the system should do with what it knows. That means linking clinical data, behavioural data, segmentation and phenotyping into logic a clinician or a health coach could actually act on. Prediction creates insight; behavioural intelligence creates action, and the logic in between is where most of the design work goes.

Some of what that logic does will sit inside the medical device boundary and some of it will sit outside. Knowing which is which, early, changes what you are able to build and how you will have to evidence it. We bring that governance and regulatory experience alongside the design work rather than leaving it to the end.

Then the working model puts it in front of the people whose reaction matters, clinicians, coaches and the people they support, while it is still cheap to change. How it would be validated is part of the same question, and we work across proof of concept, pilot and trial, so an evidence phase is shaped with the next stage of evidence already in view.

Most of this is work an internal team knows it should do and cannot find the time or the specialist cover to do. It is done here by clinicians, behavioural scientists and psychologists, decision architects, machine learning engineers, and behavioural AI and transformation specialists, drawn together for what a particular programme needs rather than working in sequence. You can meet the core team.

This is the ground our published work covers, including the FAST framework for evaluating conversational AI and our work on behavioural safety.

Why this works

Built so the answer can be no.

Independence

Sacher AI does not sell a technology platform and does not depend on winning the build that follows. That removes the commercial incentive to recommend building regardless of the evidence. It does not remove judgement, but it does mean a stop recommendation is a real possibility rather than a theoretical one.

Designed to minimise the need for patient data

Most evidence phases can run on synthetic, test, public or appropriately de-identified information. That reduces avoidable data and governance burden while the proposition, workflow and decision logic are tested. Where representative or real world data is genuinely needed to answer the decision, we say so rather than assume it away.

Regulatory boundary in view from day one

The work is shaped from the start with a clear view of where the medical device boundary sits, so what you learn stays useful when you move towards a build.

Who this is for.

Innovation, digital, clinical, product, transformation and R&D teams in health and life sciences with a credible opportunity, funding to investigate it, and a material decision they will have to defend.

And who it is not for.

This is not a production build service. It is also not designed to validate a direction that is no longer open to challenge. If the solution has already been chosen and what you need is a delivery supplier, a different engagement will suit you better.

What happens next

If you decide to go ahead.

You will not be starting from a standing start. Going ahead does not have to mean a bespoke build: the right route may be to buy, partner, integrate, or run a limited pilot first. Whichever it is, the evidence phase leaves you with the options, a pilot design, and the internal case already made. What happens after that is your decision, and it does not have to involve us.

Next step

Start with a conversation

A short call to understand what you are trying to decide, and whether an evidence phase is the right way to decide it.

Book a conversation