Working with organisations · Revised 05 Aug 2026
Working with us
We engage before the requirement is defined. Three shapes of work, each producing something you can act on — including the finding that you should not proceed.
FeasibilityPrototypeR&D engineering
The stage we work at
Most technical suppliers begin where the requirement ends. You describe what is to be built; they build it; the risk they manage is delivery risk. That model works well and there is no shortage of good firms doing it.
Volunos exists for the stage before that, where the requirement cannot yet be written because nobody knows whether the thing is possible, at what cost, or with what error. The risk being managed is not delivery risk but technical uncertainty — the possibility that the approach does not work at all, or works only under conditions the business cannot accept.
If you can already write the specification, you do not need a lab. If writing it would require you to guess, that guess is what we are for.
The practical difference shows up in what we are paid to produce. A study that concludes "this does not work, here is the evidence, here is what we would try instead" is a successful engagement. It has removed a wrong path early, which is normally the cheapest thing a research budget can buy.
Three engagement shapes
These are shapes rather than packages. Every engagement is scoped against a specific question, and the duration lines below describe what work of this kind has typically needed, not a price list.
Feasibility study
You have a technical question with no reliable answer inside the organisation. We frame it precisely, agree what would count as evidence either way, run the smallest experiment that settles it, and write up what we found — including the case where the answer is no.
Typically 3–6 weeks · Written findingsPrototype build
For questions a study cannot settle, where the answer only appears in something that runs. We build the narrowest artefact that exercises the uncertain part — not a product, not a pilot — and report where it holds, where it fails, and what production would demand of it.
4–10 weeks · Working artefactR&D engineering
Laboratory code that has proved itself and now has to survive a production system. We make it maintainable, testable and observable, and keep the technical documentation and experiment records that an R&D tax relief claim has to be able to stand on.
Ongoing · Code + evidence recordHow a study runs
Step 01
Framing the question
A conversation, usually an hour, sometimes two. The output is a single written question with the ambiguity removed, and an agreed statement of what evidence would settle it in each direction. If that statement cannot be written, the engagement should not start — an unfalsifiable question consumes budget indefinitely.
We also establish at this point whether the answer already exists in the literature or in your own organisation. Occasionally it does, and we say so.
Step 02
Scope, access and materials
A short scoping note setting out method, duration, what we need from you, and what will be delivered. Where the work needs your data, code or hardware, we agree what is provided, on what terms, and how it will be handled and destroyed. Confidentiality obligations are agreed before anything sensitive moves.
Where the question can be answered on synthetic or anonymised data, we prefer that, and will suggest it.
Step 03
The work, recorded as it happens
Experiments are run against the agreed criteria and recorded contemporaneously: hypothesis, method, parameters, result, date. You get a short written update at an agreed interval — normally weekly — including when the news is that an approach has failed. Nothing is saved up for a reveal at the end.
Step 04
Findings you can act on
A written report: the question, the method, what we observed, what we can and cannot conclude from it, the conditions under which the conclusion holds, and what we would do next. Where a prototype was built, the code and instructions to run it come with it. Where the finding is negative, it is stated as a finding, not softened.
The report is written to be readable by an engineering lead and by a finance director, because both usually have to act on it.
What we are not
Being specific about this saves everyone time, and there are competent firms — some of them run by people we know — for each of the following.
- Not a custom software agency. We do not take a defined specification and deliver an application against it. If your requirement is written and understood, you want a delivery firm, and a good one will be cheaper and faster than us.
- Not a data platform builder. We model engineering data as part of research; we do not build or operate warehouses, pipelines or reporting stacks as a service.
- Not an AI assurance or model-reliability firm. We study whether an approach works. Ongoing evaluation, monitoring and assurance of a deployed model is a different discipline with different obligations.
- Not a managed service provider. We do not run infrastructure, hold support rotas, or provide helpdesk cover.
- Not tax advisers. We produce and maintain the technical record and narrative that an R&D relief claim relies on. Whether a claim can be made, and its preparation and submission, is a matter for your accountant or a qualified adviser, and we will say so every time it comes up.
Materials, confidentiality and intellectual property
Research engagements involve receiving material that matters: unpublished designs, measurement data, source code, process detail. Our default position, which is written into our terms in full, is set out below in summary.
Confidentiality
Material you give us is confidential, is used only to perform the engagement, is disclosed only to the people working on it, and is returned or securely deleted at the end of the engagement on request. We will sign your non-disclosure agreement where you have one, and we have our own where you do not.
Background and foreground intellectual property
Background IP — what each party brings to the engagement, including our internal tooling, harnesses, libraries and methods — stays with the party that brought it. Foreground IP created specifically for you in the course of the engagement is assigned to you on payment, subject to a licence back to us for our internal tooling and for the general know-how that any competent practitioner carries away from work of this kind.
Our own internal research, including the entries in our ledger, is our IP and is not exclusive to any client. Where an engagement would require us to give up rights in existing internal work, we will say so before it starts rather than discover it at contract stage.
Publication
We do not publish anything arising from client work without written agreement on the wording. Internal research may be published at our discretion, provided it contains nothing confidential to a client and nothing that could identify one.
Data handled during research
Where an engagement requires personal data, we act as processor on your written instructions under Article 28 of the UK GDPR. We prefer anonymised or synthetic data wherever the question can be answered without the real thing. The detail — sub-processors, transfers, retention, deletion at engagement end — is in our privacy notice.
Starting a conversation
Send a paragraph, not a brief. What are you trying to find out, what have you already tried, and what would change if you knew the answer? That is enough for us to tell you whether this is work we can usefully do.
Reply within 2 working days · No contact form on this site