Pre-Launch Hardware Validation Checklist

You have a niche device idea, a sketch, and a growing urge to make it look official. The next tempting move is to buy tooling, file paperwork, or build a deck before the thing actually works.

The first job is to prove the core promise on a board you can hold, then mark what still fails. A project called RotaryCell makes the line clear: it lets an unmodified rotary phone operate as a battery-powered cellular phone. It uses a LilyGO T-A7670G-S3 Standard board that provides the ESP32-S3 controller, A7670 modem, battery charging, and cellular audio interface. On September 6, 2026, RotaryCell's first JLCPCB Audio/Reset A4 and AG1171 carrier boards had been assembled, and firmware v0.10.4-supported functions passed initial testing on the new assembly. As of September 6, 2026, RotaryCell was still an active validation, not a completed construction release, because firmware lacked working automatic-reset and AG1171 power-down controls.

A working core function is evidence. A deck, a logo, and a filed entity are packaging. If the core function has not passed a narrow test, the packaging hides the risk instead of revealing it.

Visible progress can hide an unproven device

Tooling feels like progress because it is visible. A tooling order, a new name, or a branded enclosure gives you something to photograph. Incorporation creates a legal identity, and a pitch deck makes the idea look fundable. None of those steps proves the device does the one thing it must do.

A feasibility prototype is recommended before development starts to catch risks and wrong techniques early, and it is often shown to investors and stakeholders in pitch meetings. A pitch deck is usually a 10-15-slide overview of a startup's product, business model, market, team, finances, and fundraising needs. In the Button City deck, the screenshots slide was meant to send investors to a working prototype or trailer, the most important asset in a game pitch. The deck should point to something that works, not replace it.

For a pre-incorporation hardware maker, the safest order is simple. The device has to prove itself before the next dollar leaves the account.

Run a pre-tooling validation before the idea gets romantic

Use this list as a gate. Each item is small enough to test in a minute, and the list is short enough to finish before the next purchase.

State the core promise as a single observable behavior. Write it as: when I do X, the device does Y. If you cannot watch it happen in a minute, the promise is too vague to spend on.
Build the smallest off-the-shelf proof. Use a single board, a single power source, and the minimum parts needed to trigger the behavior. No enclosure, no branding, no final layout.
Run a single narrow test with a pass/fail line. Define the exact input, the exact output, and the condition that counts as failure. Run it once, then record the result.
Keep a failure log. Add a single line for each miss: date, input, expected result, actual result, next change. The log is the map of what remains unvalidated.
Set a go/no-go spend rule. Name the spend you will not make until the core promise passes: tooling, incorporation, customer acquisition, or a deck for investors. If the rule is not written down, it will bend.

The list works because it forces the device to show its work. It also keeps the unvalidated parts visible, so you do not accidentally treat a partial success as a finished product.

The spend rule decides whether the next dollar is earned

The hardest item is the last one. It turns validation into a decision instead of a mood. If the core promise passes, you can spend with more confidence. If it fails, you have saved the cost of tooling, paperwork, and a deck that would have described a device that does not work.

Make it work. Then make the next narrow test, and only then spend.