Gate checklist says FAIL on 20+ items — is my product idea dead?

[yoelf22]

Ran Electrum on a connected pet feeder (WiFi, load cell for portion tracking, companion app). The gate checklist came back with 23 FAILs out of 90 items. Some feel serious (no OTA update strategy, no defined behavior for WiFi dropout mid-dispense) but others feel nitpicky (no EMC pre-scan plan, no defined thermal management strategy).

At what FAIL count should I be worried? Is there a way to triage which FAILs actually matter at this stage vs. which can wait until later in development?

[yoelf22]

23 FAILs on a first pass is normal. The checklist is intentionally comprehensive — it's designed to surface questions, not to score your product. A high FAIL count doesn't mean the idea is bad. It means you have 23 conversations ahead of you.

How to triage FAILs

Sort them into three buckets:

Bucket 1: Architecture FAILs (fix now)

These are FAILs that, if answered differently, would change the system architecture. For your pet feeder:

• No OTA update strategy — this determines whether you need a dual-bank flash layout, which affects MCU selection, which affects BOM cost. Answer this before you pick components.
• No defined behavior for WiFi dropout mid-dispense — this is a safety question (does the motor keep running? does it complete the portion? does it stop and retry?). The answer shapes the firmware state machine.

If a FAIL would change your block diagram or your component choices, it's Bucket 1. Fix it now by revising the system description.

Bucket 2: Specification FAILs (fix before prototyping)

These are FAILs where the answer won't change the architecture, but you need the answer before you can build a working prototype:

• No EMC pre-scan plan — you don't need to do the scan now, but you should know which standard you're targeting (FCC Part 15 for US, CE for EU) because it affects antenna placement and shielding.
• No defined thermal management strategy — for a pet feeder with a small motor and WiFi SoC, this is probably "passive cooling, verify with thermal camera during DVT." Write that down and move on.

Bucket 2 FAILs need a one-sentence answer, not a redesign.

Bucket 3: Process FAILs (fix before manufacturing)

These are FAILs about manufacturing, testing, and lifecycle management. They're real, but they don't block concept validation:

• Factory test procedure, packaging spec, warranty policy, field return process
• These can wait until you've validated the core product

Rough benchmarks

From the examples I've run:

Product complexity	Typical first-pass FAILs	After one revision
Simple (few sensors, no connectivity)	10–15	3–5
Medium (BLE/WiFi, companion app, 1–2 actuators)	20–30	8–12
Complex (multiple sensors, cloud backend, mechanical subsystems)	30–45	12–20

Your 23 FAILs on a WiFi-connected device with a motor and load cell is right in the expected range.

The real signal

The FAIL count matters less than which FAILs surprised you. If all 23 are things you already knew you'd need to address, the product concept is solid — you just haven't written everything down yet. If 5 of them made you say "I hadn't thought of that," those 5 are the value of the exercise.

For the pet feeder specifically: the WiFi-dropout-mid-dispense question is the one I'd focus on. A pet feeder that delivers the wrong portion because of a network glitch is a product recall waiting to happen. That's a Bucket 1 item that should drive your firmware architecture.