Approach
Research is expensive to do badly and the cost usually arrives late. Almost everything in how we run a programme is designed to move that cost forward, to the point where it is still a decision rather than a write-off.
Five stages, in this order for a reason
Not every programme runs all five, and the boundaries are less tidy in practice than they look here. The order, though, is deliberate: each stage exists to make the next one cheaper or unnecessary.
Framing
Turning a situation into a question that can actually be answered.
Most failed programmes were unanswerable from the start. Before anything is built we agree what would count as an answer, what evidence would change the conclusion, and what the work is worth if the answer turns out to be no.
Feasibility
The cheapest experiment that could sink the idea, run first.
We look for the assumption carrying the most weight and test that one before anything else. It is an uncomfortable order — it front-loads the risk of an early stop — but it is considerably cheaper than discovering the same thing after a year of integration work.
Build
Hardware, firmware and analysis developed against real constraints.
Power, cost, environment and regulatory obligations are treated as inputs rather than late-stage discoveries. We build the smallest thing that settles the question, then extend it only where extension is justified.
Evidence
Evaluation designed to find failures, not to confirm the result.
We define the evaluation before we see the outcome, report performance by condition and subgroup rather than only in aggregate, and document what the system was never tested under. Negative results are delivered with the same care as positive ones.
Transfer
Work handed over so someone else can carry it.
Source, schematics, test fixtures, data-processing steps and the reasoning behind the significant decisions. A deliverable that only works while we are in the room has not been delivered.
The parts clients sometimes find inconvenient
We report what did not work
A negative result that arrives early is one of the more valuable things a research programme can produce. Suppressing it to protect a narrative costs the client far more than it saves.
We will tell you not to build it
If an existing product solves the problem, or the physics does not support the requirement, or a learned model is the wrong tool for a task a filter would handle — we say so, before the budget is committed rather than after.
Scope is a question, not a list
Deliverable lists drift because nobody can say whether an addition belongs. A well-framed question makes that judgement obvious and keeps the programme honest about what it is for.
Constraints belong at the start
Energy budgets, regulatory pathways, manufacturability and data-protection obligations shape the design. Introduced late, they are a redesign; introduced early, they are just engineering.
Evidence over assertion
Claims about a system are backed by a stated method, defined conditions and reproducible results — including a clear account of the conditions under which it was never tested.
Your confidentiality is not our marketing
We do not publish thinly anonymised case studies. Where a client wants work written up, we do it properly, with their name on it and their approval.
How programmes usually start
Most engagements begin with a short, paid framing exercise rather than a proposal written against an incomplete brief. It produces a question, a view on what would answer it, and an honest estimate of what that would take — which is enough for either side to decide not to continue.
We work under client confidentiality as a matter of course, and we are used to programmes where intellectual property, regulatory obligations and third-party dependencies all need settling before the interesting work can begin.