Functional prototype, proven.
Also called: Works-like prototype · Functional rig · Proof-of-function build · Engineering breadboard
A rough rig that proves the function works, instrumented and logged against the spec, so the numbers decide instead of a hopeful impression.
Build the working guts before the pretty shell. A functional prototype proves the product does its job, measured against the spec, not that it looks finished. Instrument it, run it overnight, log the data, and let the readings tell you what the model and the sims could not.
What a functional prototype is
A functional prototype is a build that does the job, even if it looks like it was assembled on a kitchen table. It is a works-like, not a looks-like. The point is not to impress anyone; the point is to prove that the core function actually performs, on real hardware, in conditions close to the ones the product will live in.
That word “measured” is doing the heavy lifting. A prototype that “seems to work” tells you almost nothing. A prototype with a sensor and a data log tells you whether it holds the spec, by how much, and where it struggles. The difference between those two is the difference between an opinion and an engineering decision. If you cannot point at a number, you have not finished the activity.
Why this gets rushed
- The model looked fine. CAD and simulation are confident right up until physics disagrees. A functional prototype is where the model meets a cold kitchen and finds out which one was wrong.
- It is ugly, so it feels unfinished. Teams want to skip to the nice enclosure. But a beautiful box that holds the wrong temperature is a beautiful failure. Prove the function first; dress it later.
- Logging feels like overkill. Watching it run for ten minutes and nodding is not a test. The failures you care about (overnight drift, slow recovery, a warm spot) only show up in hours of logged data.
How we measured it
For the proofing box, the functional prototype was a real heating element, a temperature sensor, and a control board wired to a logger. No ceramic shell, no wood, no finish. It looked rough. The question it answered was the only one that mattered at this stage: does it hold 26°C ±0.5°C on under 30W, through a real night, in a real cold kitchen? Here is the rig sheet from that build, so you can see the shape of a good answer rather than a generic template.
The surprises row is the whole reason you build the thing. The recovery time and the warm spot were invisible in CAD and only showed up because the rig ran overnight with a logger attached. That is the lesson a functional prototype exists to teach.
- “I held my hand in it, felt about right.”
- “Ran it for ten minutes, looked stable.”
- “The model said 26°C, so it’s 26°C.”
- No log, no power figure, no overnight run.
- Held ±0.4°C across an 8-hour night.
- Settled at 24W, comfortably under the 30W cap.
- Recovery after lid open: 6 minutes, logged.
- Data file you can hand to the next stage.
The left column is a feeling. The right column is a decision you can defend. Only one of them survives contact with a customer, a reviewer, or a UKCA file.
How it fits the bigger picture
Functional prototype is activity 08.10.04 in Stage 08 Develop. It takes the proven function and hands it forward to the pre-production prototype (08.10.05), where the verified guts move into the real ceramic shell and the build starts to look like the finished product as well as work like it.
What it can do
It proves the core function on real hardware and surfaces the failures the model and the sims could not see. It turns “we think it holds temperature” into a logged number you can take into the next stage, the spec sign-off, and eventually the BS EN 61010 file.
What it can’t do
It can’t tell you whether the product will sell, and it isn’t the production design. It is rough on purpose. Tooling, finish, cost-down and the looks-like build all come later. Treat its results as proof of function, not proof of a manufacturable product.
See the full 10-stage process →
Try it yourself
Take your riskiest function and build the smallest rig that performs it, with no enclosure and no finish. Wire in a sensor and a logger before you switch it on. Define the spec number you are testing against first, then run it long enough for the slow failures to appear (overnight, if it runs overnight). Read the log, not your impression. Whatever the data says is the answer.
Want to scope the function worth proving first? Start the Free Sprint → and the GPT will help you name the riskiest one.
Your functional-prototype checklist
Project notes: the overnight log
▸ From the notebook · optional reading
Project notes: a rough rig and a cold kitchen
Dan and Anna’s first proofing box looked like nothing. A logger left running overnight in a Stockport kitchen told us what the model never could.
3 min read · click to open
The CAD and the thermal sim both said the box would hold 26°C on around 22W. Dan wanted to go straight to the ceramic shell. I asked for one thing first: a rough rig and a night of data.
The rig was the heating element, a sensor, and the control board on a breadboard, sitting in a plain plywood box with a loose lid. It looked like nothing. We set 26°C ±0.5°C and under 30W as the pass marks, wired in a logger reading once a second, and left it running overnight in their Stockport kitchen, which sat around 14°C by the small hours.
What the log said in the morning
The good news held. It sat at 26°C, drifting no more than ±0.4°C all night, and settled at 24W once warm. Warm-up from cold was 11 minutes. On the headline numbers, the model was right.
Then the two surprises. First, recovery: every time the lid opened, the model said it should be back to setpoint in two or three minutes. The log showed six. In a cold kitchen, the heat leaving when you check the dough is real, and the cheap element could not claw it back as fast as the sim assumed. Second, a warm spot. The sensor near the element read fine, but a probe in the far corner ran almost a degree cooler. The box held its average and hid a gradient.
Neither of those would have shown up in a ten-minute bench check, and neither was visible in CAD. We pushed the element placement and added a small baffle to even out the air, then re-logged a second night to confirm the gradient closed. The recovery time we simply accepted and documented; six minutes is fine for an overnight prove.
That rough box, ugly as it was, earned its keep. It turned two assumptions into measured facts and saved us from finding the warm spot in the £149 production unit, where it would have cost a tooling change.
— Develop stage, project notes, 2026
— Next in Develop → Pre-production prototype