A Prototype Is a Question with Edges

A prototype is often treated as a small version of a finished product. In wet-lab work, I find it more useful to treat it as a question with edges: a deliberately bounded system that makes one uncertainty easier to see.

A prototype is not a promise of scale

When a prototype is judged too early by whether it looks like the final platform, it starts carrying the wrong burden. It must be compact, reproducible, affordable, representative, and ready to scale, all at once. That pressure can hide the actual reason for building it.

The first job of a prototype is not to prove that the final system will work. It is to make a meaningful uncertainty cheaper to investigate. A good prototype tells us what to measure, which assumption is fragile, and what kind of failure deserves attention before more resources are spent.

Give the question an edge

“Can this wet-lab system work?” is too large to guide a useful first build. A question with edges is narrower: can the material remain stable over the intended time window? Can the interface preserve the relevant cell state? Can a simple readout distinguish the response from background drift?

Each version should have a boundary around what it is trying to learn. The boundary is not a weakness. It is what makes the result interpretable. If the prototype changes five things at once, a successful result becomes difficult to attribute and a failed result becomes difficult to diagnose.

This is especially important in living systems, where small differences in handling, timing, surface chemistry, or environment can become large differences in outcome. The prototype should expose those sensitivities, not hide them behind a polished enclosure.

Build the uncertainty into the workflow

A wet-lab prototype is not only a piece of hardware. It is a workflow: a preparation method, an interface, a sequence of interventions, a set of controls, a measurement, and a decision about what happens next.

If the workflow is not recorded, the prototype can appear less variable than it really is. Unwritten choices become invisible sources of drift. A useful system therefore records the choices that matter, even when they feel too ordinary to document: order of addition, waiting time, handling conditions, failed runs, and changes made during the experiment.

The point is not to produce paperwork. It is to preserve the path by which a result was made. That path is part of the system being prototyped.

Failure is information at the right scale

A prototype can fail in many ways: the material cannot be prepared consistently, the interface damages the sample, the measurement is too noisy, or the desired state is not maintained for long enough. These are not interchangeable failures. Each points to a different next question.

The value of a small prototype is that these failures can be separated before they become entangled in a large platform. The system does not need to answer everything. It needs to make the next distinction possible.

What the prototype is allowed to be

A prototype is allowed to be ugly, slow, manual, and incomplete. It is allowed to use a temporary fixture or a measurement that will later be replaced. It is allowed to reveal that the original question was poorly posed.

What it should not be is ambiguous. We should know what was intentionally simplified, what was held constant, what was measured, and what remains outside the claim. A prototype earns the right to become a platform by making its own boundaries visible.