Proof-of-concept vs prototype: which build do you actually need?

3D printer producing a white lattice prototype part

“Can you build us a prototype?” is probably the most common opening question we get, and about half the time a prototype isn’t actually what the project needs next. The words get used interchangeably, but in device development they describe different builds that prove different things, at quite different costs. Picking the wrong one wastes money, and more importantly it wastes time you may not have before the funding runs out.

So here’s the vocabulary, and my view on how to choose.

Proof-of-concept: does the core idea work at all?

A proof-of-concept build exists to answer one question about the riskiest part of your idea. Can this mechanism deliver a repeatable dose? Will this seal survive a thousand cycles? Does the sensing approach actually detect what we think it does?

It doesn’t need to look like a product. Quite often it’s a lump of aluminium and some 3D printed parts clamped to a bench, wired up to instruments, and that’s absolutely fine. Every pound spent making a proof-of-concept pretty is a pound not spent answering the question.

The output that matters isn’t really the hardware, it’s the measurement. A rig, a test method and a set of recorded results turn “we believe” into “we’ve measured”, and that changes the conversation with investors and grant reviewers considerably.

Works-like: the physics in one box

A works-like build functions the way the final device will (right mechanism, right performance) but doesn’t look the part. Off the shelf parts, oversized housings, exposed fixings, none of that matters. It exists so you can test performance honestly and iterate quickly while the design is still cheap to change.

Looks-like: the product in your hand

A looks-like model has the form, size, weight and finish of the intended product, but doesn’t need to function. It earns its keep in usability sessions, clinician feedback, and any meeting where someone needs to hold the thing to believe in it. Investors respond well to looks-like models, and so do surgeons.

I’d recommend keeping works-like and looks-like separate for as long as you reasonably can. Combining them too early gets expensive, as every design change then has to satisfy function and form at the same time.

Prototype: bringing it together

A true prototype brings function and form together, so the device as intended, made by methods reasonably close to production. This is the build you take into formal verification testing, and by this stage changes cost real money. Ideally you arrive here with the big questions already answered by the cheaper builds above.

What funders actually expect

Grant reviewers and investors aren’t fooled by polish, and the good ones are actively suspicious of it. An Innovate UK or NIHR reviewer reading an early stage application wants to see that the technical risk has been identified and addressed, and as such a proof-of-concept with real measured data is worth quite a bit more than a beautiful looks-like model with none. Later stage funders flip the emphasis, as by then they expect the works-like data to exist and want evidence that real users have held something.

If you’re preparing a funding application, my advice would be to match the build to the claim you need to make, rather than to what looks best in the photos.

The expensive mistake

The pattern we see most often is a team spending its first serious money on a build that looks finished (it feels like progress and it demos well) before the core technical risk has been retired. Testing then finds a problem, and fixing it means unpicking an integrated, polished design rather than swapping a bracket on a bench rig. Fixing it at that stage costs several times what it would have done a stage earlier.

The discipline is fairly boring but it does pay: build the cheapest thing that answers the current question, measure it properly, then move up a level.

Where we fit

We do all four types of build in-house near Bristol, from bench rigs and proof-of-concept hardware through to verification ready prototypes, with the test data recorded properly so it feeds into your technical file rather than sitting in a drawer. If you’re not sure which build your project needs next, I’d be happy to have a call to help you work it out. It’s a 30 minute conversation that regularly saves people months. You can book a free call here.