Define “it works” before you build.

Start with the question the prototype should answer

An appearance model may answer whether a product is comfortable to hold. A functional sample may answer whether a sensor can be read and shown on a display. A prototype that answers one question should not automatically be described as ready for production.

Choose the few functions needed for the first learning goal. List deferred features separately, such as wireless setup, battery operation or a production PCB. This makes the first build easier to evaluate and prevents a new feature from quietly changing the definition of success.

Write a check someone else can repeat

Give each requirement an identifier, setup, action, expected result and record to keep. Include the hardware revision, firmware version, power source, relevant environment and measuring equipment. Decide who reviews the result.

A proposed teaching example is: “After power is applied through the intended USB cable, valid temperature and humidity readings appear within 10 seconds.” Record each startup and its timing. The 10-second value is a project target to agree, not a universal specification or a result we have achieved.

Replace “the enclosure is good” with observable checks: the lid closes without trapping wires; the intended plug can be connected; the agreed fastening procedure holds the boards. Define dimensions, forces or other limits where the project needs them.

Check failure behavior and measurement limits

Decide what a user should see when a reading is unavailable. A clear error state is easier to interpret than a stale number presented as current. Review a safe way to simulate the fault; for the proposed low-voltage demo, disconnect power before changing sensor wiring, then restart.

Display resolution is not measurement accuracy. Showing two decimal places does not establish that the complete device is accurate to those places. A comparison with another desktop meter can reveal differences, but it does not establish calibration.

For a sensor in an enclosure, compare open and enclosed behavior under recorded conditions. Electronics can warm the enclosure and restricted airflow can affect response. Record observations and uncertainties before deciding whether a layout change is needed.

Keep the results and the decision together

Use a result record with pass, fail or not tested; the actual observation; an evidence filename; and the next decision. If something fails, keep the failed result, identify the design or test change and repeat the affected checks under a new revision.

At handoff, list delivered hardware, file revisions, firmware where included, inspection or test records and known limitations. A functional demonstration alone does not establish durability, regulatory compliance or manufacturing readiness; those require their own scope and evidence.