The Recipe, Not the Code: Rethinking Continuity Protection in UK Deep Tech

When a UK deep-tech company reaches the point of institutional investment, the term sheet often borrows a familiar comfort from the software world: source-code escrow. The instinct is understandable. Investors want a mechanism that preserves continuity if founders depart or a company enters insolvency. But in businesses built on process recipes, calibration baselines, supplier setup data and operator judgement, a repository of code can be a reassuring artefact that answers the wrong question.

The issue is not that escrow is useless. It is that the standard clause has become a proxy for continuity without a serious test of whether the underlying business could actually be rebuilt. For UK deep-tech investors and founders, the gap between the document and the operational reality deserves more attention than it currently receives.

Why the software template travels badly

Software escrow rests on a simplifying assumption: the valuable logic is written down, modular and portable. Given the source, a competent team can compile, deploy and maintain the product. Deep tech rarely behaves this way. A materials spinout may depend on a particular furnace ramp profile, a catalyst activation procedure or a cleaning regime developed through trial and error. A robotics company may rely on fixture tolerances, vision-system calibration files and a supplier's undocumented firmware configuration. An energy-hardware firm may hold test-bench settings that took months to stabilise.

None of this fits neatly into a source-code repository. Some of it is written down, some is embedded in equipment, and some sits in the heads of a small number of engineers. A standard escrow agreement may capture software repositories and perhaps a set of documents, but it typically says little about the physical and tacit knowledge that makes those assets productive.

The result is a diligence blind spot. Investors can confirm that an escrow agreement exists, that a custodian has been appointed and that the deposit has been made. They are less able to confirm that the deposit would allow a third party to reproduce a saleable product, qualify a process or keep a pilot line running.

What a deep-tech continuity package should contain

A credible know-how escrow for a UK deep-tech business needs to be assembled around reproducibility rather than around file formats. That means starting with a simple question: what would a competent replacement team need in order to operate the business at its current state, not at some earlier stage?

The answer usually spans several categories. First, process definitions: recipes, set-points, tolerances, bill-of-materials variants and the rationale behind them. Second, calibration and measurement baselines: instrument settings, reference standards, uncertainty budgets and the history of adjustments. Third, supplier and equipment setup data: tool configurations, firmware versions, maintenance schedules, spare-parts lists and the identity of critical subcontractors. Fourth, quality and test evidence: acceptance criteria, failure logs, rework procedures and the records that show how a process was validated. Fifth, operator knowledge: training materials, standard operating procedures and, where possible, structured interviews or recordings that capture the judgement calls that never make it into a manual.

This is not a call for indiscriminate documentation. Excessive paperwork can be as misleading as none at all. The point is to identify the minimum set of artefacts and tacit inputs that would let a technically competent party restart, rather than merely inspect, the operation.

The rebuild test

A useful diligence exercise is to ask whether the company could survive a controlled rebuild. This can be done as a tabletop exercise without disrupting the business. The investor or an independent technical adviser selects a critical process or product line and asks the management team to demonstrate, from the escrowed materials alone, how a new team would reproduce it.

The test tends to expose three common failures. The first is missing context: a recipe exists, but the reason for a particular hold time or atmosphere is absent. The second is missing access: the data is held by a supplier or a departed engineer and is not actually deposited. The third is missing verification: the escrow contains documents, but no one has checked that they are current, complete or internally consistent.

Running the exercise before completion, rather than after a crisis, gives founders a chance to close gaps and gives investors a more honest basis for pricing key-person risk. It also creates a record of what was tested and when, which is useful in later rounds and in exit diligence.

Making escrow operational, not ornamental

Several design choices separate a credible arrangement from a ceremonial one. The trigger conditions should be specific and practicable, covering not only insolvency but also prolonged incapacity, loss of a critical licence or the departure of named key personnel. The custodian should have the technical competence to assess whether a deposit is complete, or should work with an independent technical verifier. The agreement should require periodic updates, because a deposit that reflects the company as it was two years ago may be worse than no deposit at all. And the release mechanism should be tested in advance, at least in outline, so that neither party discovers a procedural blockage when speed matters.

For UK founders, there is a negotiation point here. A well-scoped know-how escrow can be presented as an asset rather than a burden. It demonstrates operational maturity, supports grant and procurement conversations, and can reduce the discount investors apply to key-person concentration. For investors, it offers a more defensible continuity position than a standard software escrow deed that no one has stress-tested.

The diligence question that matters

UK deep tech is increasingly judged on its ability to scale manufacturing, qualify processes and win repeat orders. Those are operational achievements, not merely intellectual-property ones. Continuity protection should reflect that reality. The right question is not whether a company has an escrow agreement, but whether a competent third party could take the deposited materials, the equipment and a reasonable handover and produce the same result.

Until that question is asked explicitly, escrow will remain an illusion of protection: present in the data room, reassuring in the term sheet, and silent on the thing that actually matters. The recipe, the calibration and the operator's hard-won judgement are the assets that need protecting. The code, where it exists, is only one ingredient.