DEMOGOD
What Shipping 500 Hardware Units Teaches About Voice AI Verification (And Why "Ship And Hope" Fails)
# What Shipping 500 Hardware Units Teaches About Voice AI Verification (And Why "Ship And Hope" Fails)
**Meta Description:** A software engineer shipped 500 hardware units and learned Murphy's Law the hard way. Every lesson applies to Voice AI: anything not verified WILL fail. Context-first beats ship-and-hope.
---
## When Software Engineers Hit Hardware Reality
HN #1 right now (332 points, 174 comments): **["Lessons Learned Shipping 500 Units of my First Hardware Product"](https://www.simonberens.com/p/lessons-learned-shipping-500-units)** by Simon Berens.
The story: Software engineer quits job, launches [Brighter](https://getbrighter.com/) (world's brightest lamp), raises $400k in crowdfunding, manufacturers 500 units in China.
**The result:** Every single thing that wasn't explicitly verified went wrong.
From the article:
> "Anything that can go wrong will go wrong. Anything you don't specify will fail to meet the implicit specification."
And my favorite:
> "I truly began to appreciate Murphy's law. In my case, **anything not precisely specified and tested would without fail go wrong and bite me in the ass**."
This is the exact same lesson Voice AI learned in production.
**Hardware:** If you don't verify heatsink dimensions, the factory moves injection pins inside the fins and destroys the part.
**Voice AI:** If you don't verify DOM element refs, the agent clicks the wrong button and breaks the demo.
Both domains share the same brutal truth: **Verify first, or fail later.**
---
## The "It Tested at 39,000 Lumens" Moment
Simon's first crisis:
> "The tagline of Brighter was it's 50,000 lumens — 25x brighter than a normal lamp. Instead, despite our planning & calculations, **it tested at 39,000 lumens** causing me to panic."
**The software engineer's assumption:** "We calculated it, so it should work."
**Hardware reality:** Doesn't matter what you calculated. **Test or fail.**
They fixed it (redesigned electronics, bigger heatsink, better diffuser transmission), and overshot to 60,000 lumens.
**But here's the key:** They only discovered the problem because they **verified before mass production**.
---
## The Voice AI Equivalent: DOM Snapshot Verification
Voice AI has the same problem, but faster.
**Software engineer's assumption:** "The user said 'click checkout', so just execute `page.click('.checkout-btn')`."
**Production reality:** The checkout button moved. Or the class changed. Or a modal appeared. Or the session expired.
**Result:** Agent clicks wrong element, demo crashes, customer sees failure in real-time.
Demogod's solution: **Verify DOM state before every action.**
```
User: "Navigate to checkout"
AI actions:
1. Capture DOM snapshot (full page state)
2. Verify elements exist:
- Checkout button: ✓ Found, ref verified
- Cart state: ✓ 3 items present
- Session state: ✓ 8 minutes remaining
3. Identify edge cases:
- Session <10 min = warn user before multi-step action
4. Execute action with verified ref
5. Verify state change (page navigated to checkout URL)
```
**Anything not verified WILL fail.**
Just like hardware.
---
## The Heatsink Disaster: When Verification Fails
Simon's second crisis:
> "Due to a miscommunication with the factory, the injection pins were moved inside the heatsink fins, causing cylindrical extrusions below. I was just glad at least the factory existed."
**What went wrong:** Specifications weren't precise enough. Factory made assumptions. Heatsink was fucked.
**The cost:** Weeks of delay, remade mold, wasted inventory.
**The lesson:** Implicit specifications don't count. **Verify explicitly or fail silently.**
---
## Voice AI's "Heatsink Moment": The Session Expiry Edge Case
Traditional web automation (implicit verification):
```javascript
// Selenium script
await page.click('.add-to-cart');
await page.click('.checkout-btn');
await page.fill('#email', user.email);
await page.click('.submit-order');
// Hope everything worked
```
**What's not verified:**
- Does `.add-to-cart` still exist?
- Did the page navigate after click?
- Is the session still valid?
- Did a modal interrupt the flow?
**Result:** Script breaks mid-execution, no idea why, debug nightmare.
---
## Voice AI (explicit verification at every step):
```
User: "Complete checkout"
AI action sequence:
1. Verify cart state:
- Read DOM snapshot
- Confirm cart has items
- Check session validity (8 min remaining)
2. Navigate to checkout:
- Verify checkout button exists (ref validated)
- Click verified element
- Verify navigation (URL changed to /checkout)
3. Fill form:
- Read DOM for form fields
- Verify each field ref before filling
- Check for validation errors after each input
4. Submit order:
- Verify submit button enabled
- Check for blocking modals
- Confirm session still valid (1 min remaining)
- Execute OR warn: "Session expiring soon, proceed now?"
```
**Every step verified. Every edge case surfaced.**
No silent failures. No implicit assumptions.
---
## Lesson #1: "Plan Way, Way More"
From Simon:
> "If you mess up tooling, or mass produce a part incorrectly, or just sub-optimally plan, **you set back the timeline appreciably and there's nothing you can do but curse yourself**."
**Hardware:** Gantt charts, double your timelines, account for every step.
**Software:** Tickets, sprints, missed deadlines = reprioritize, no harm done.
**Voice AI:** Closer to hardware than software.
Why?
Because **Voice AI executes in production, in front of users, in real-time**.
You can't:
- Rollback a failed navigation (user already saw it break)
- Patch a broken demo mid-session (customer lost confidence)
- "Ship fast and fix later" (there is no later, demo is NOW)
**Voice AI requires hardware-level planning:**
- Account for every DOM state change
- Plan for session expiry edge cases
- Verify element refs before acting
- Test on multiple page states
**"Ship and hope" doesn't work when users watch you fail in real-time.**
---
## Lesson #2: "Overcommunicate. Overspecify. Follow Up."
Simon's most important lesson:
> "Anything you don't specify will fail to meet the implicit specification. Any project or component not actively pushed will stall."
**Hardware examples from the article:**
- **Heatsink:** Didn't specify injection pin locations → Factory moved them → Part destroyed
- **Control tube:** Didn't specify wire length from base → Factory stuffed too much wire inside → Customers couldn't assemble
- **Screwdriver:** Didn't specify sub-supplier quality → Got two different screw types, one broken, one dull
**Every implicit assumption became a production failure.**
---
## Voice AI's Implicit Assumptions That Kill Demos
**Implicit assumption #1:** "The checkout button will have class `.checkout-btn`"
- **Reality:** A/B test changed it to `.btn-checkout`
- **Result:** Agent can't find button, demo breaks
**Implicit assumption #2:** "Form fields will be visible when page loads"
- **Reality:** Progressive disclosure hides fields until previous section completes
- **Result:** Agent tries to fill hidden fields, fails silently
**Implicit assumption #3:** "Session will last long enough for multi-step action"
- **Reality:** Session expires mid-checkout
- **Result:** User gets logged out, loses cart, blames demo
**Every implicit assumption = production failure.**
---
## How Voice AI Overspecifies (Like Hardware Manufacturing)
**Traditional web automation (implicit):**
```javascript
await page.click('.checkout');
```
**Voice AI (explicit verification):**
```
1. Capture DOM snapshot
2. Search for elements with:
- Text content: "checkout" (case-insensitive)
- Aria-label: "checkout"
- Role: "button"
- Visible: true
- Enabled: true
3. If multiple matches: Ask user "I see 3 checkout buttons. Which one?"
4. Verify ref points to expected element
5. Click element
6. Verify state change (URL or DOM update)
7. If state didn't change: Re-read DOM, retry or escalate
```
**No implicit assumptions. Every parameter explicitly verified.**
Just like specifying injection pin locations, wire lengths, and screw types in hardware manufacturing.
---
## Lesson #3: "Test Everything, Often, On Many Units"
Simon's testing revelation:
> "In software if you have coverage for a code path, you can feel pretty confident about it. Unfortunately **hardware is almost the opposite of repeatable**. Blink and you'll get a different measurement."
**Hardware reality:** Test on multiple units in different environments.
**Voice AI reality:** Test on multiple page states in different scenarios.
Why?
Because **DOM states are as unpredictable as hardware measurements**.
---
## Why DOM States Are Like Hardware Measurements
**Hardware:** Same heatsink, different thermal readings
- Room temperature affects dissipation
- Air flow changes results
- Measurement equipment varies
- Manufacturing tolerances compound
**Voice AI:** Same website, different DOM states
- A/B tests change elements
- Session state affects visibility
- Network latency changes timing
- User actions create unique states
**Both are non-repeatable. Both require verification at runtime.**
---
## Testing Voice AI Like Hardware (Multiple Units, Multiple Environments)
**Traditional QA (single path):**
```
Test case: User clicks checkout
1. Load page
2. Click checkout button
3. Verify URL changed
Pass ✓
```
**Voice AI verification (multiple states):**
```
Test scenarios:
1. Fresh session, empty cart → Expect: "Cart is empty, add items first?"
2. Fresh session, 3 items → Expect: Navigate to checkout
3. Expiring session, 3 items → Expect: Warn session expiry
4. Guest user, 3 items → Expect: Offer login or guest checkout
5. Returning user, saved cart → Expect: Restore previous cart state
6. A/B test variant A → Verify element refs adapt
7. A/B test variant B → Verify element refs adapt
8. Modal interruption → Detect and route around
```
**Every state verified. Every edge case covered.**
Because like hardware, **DOM states aren't repeatable—they're contextual**.
---
## The PCB Pin Swap: When Labels Don't Match Reality
Simon's debugging nightmare:
> "We're measuring voltages across every part of the lamp and none of it makes sense... At the end of the day, we finally notice **the labels on two PCB pins were swapped**."
**The problem:** Documentation said pins were wired one way. Reality was different.
**The cost:** Full day of debugging with engineers across 3 timezones.
**The fix:** Verify physical reality, not documentation.
---
## Voice AI's "Pin Swap": When DOM Labels Don't Match Behavior
**Documentation says:** "Submit button has id `#submit-order`"
**Reality:**
- Button id changed to `#place-order` in A/B test
- OR button is actually a link styled as button
- OR button is disabled until form validates
- OR button triggers modal, not submission
**Voice AI solution:** Don't trust static selectors. **Read DOM at runtime.**
```
User: "Submit the order"
AI verification:
1. Read current DOM snapshot
2. Find all interactive elements matching:
- Text: "submit", "place order", "complete"
- Role: button, link
- Enabled: true
3. Verify element is actually clickable (not hidden, not disabled)
4. Check for blocking modals or overlays
5. Execute click on verified element
6. Verify expected state change
```
**Trust runtime verification, not static documentation.**
Just like Simon learned to measure actual PCB pins, not trust the labels.
---
## Lesson #4: Geopolitics Matter (And So Do External Dependencies)
Simon's tariff crisis:
> "Trump announced 'Liberation Day' tariffs, taking the tariff rate for the lamp to 50%, promptly climbing to 100% then 150%... That was the worst period of my life; I would go to bed literally shaking with stress."
**Hardware dependency:** Manufacturing in China = exposure to tariff risk.
**Voice AI dependency:** Website uptime, API availability, session management.
---
## Voice AI's "Geopolitical" Risks: External Dependencies That Break Demos
**Dependency #1: Website uptime**
- Site goes down mid-demo
- Voice AI detects: No DOM snapshot available
- Fallback: "Website appears offline, retry in 30 seconds?"
**Dependency #2: Session management**
- Site implements aggressive session expiry
- Voice AI detects: Session invalid during action
- Fallback: "Session expired, re-authenticate or start new session?"
**Dependency #3: API rate limiting**
- Site implements CAPTCHA or bot detection
- Voice AI detects: Cloudflare challenge, ReCAPTCHA
- Fallback: "Site requires human verification, continue manually?"
**Just like tariffs, external dependencies can kill your product.**
**The solution:** Build resilience through verification and graceful degradation.
---
## Lesson #5: "Visit Your Suppliers Early"
Simon's regret:
> "I wish I had visited my suppliers much earlier, back when we were still prototyping with them... Appearing in person conveys seriousness, and I found it greatly improved communication."
**Hardware:** Visit factories to verify capabilities, catch miscommunications early.
**Voice AI:** Test on actual websites to verify DOM structure, catch edge cases early.
---
## Voice AI's "Factory Visit": Testing on Real Websites
**Prototype testing (not enough):**
```
Test on staging site:
- Clean data
- Stable DOM structure
- No A/B tests
- No session expiry
- No network issues
Result: Everything works! Ship it!
```
**Production reality:**
```
Test on live site:
- User data variations
- A/B test variants
- Session expiry
- Network latency
- Concurrent user actions
- Modal interruptions
- Form validation errors
Result: 17 edge cases discovered
```
**You can't verify what you don't test.**
Just like Simon couldn't verify factory capabilities until he visited in person.
---
## What Simon Did Right: Validation Before Commitment
Before manufacturing, Simon:
1. Set up simple website
2. Let people pay $10 for discount reservation
3. Validated demand before committing time/money
**Result:** People paid even when only product photos were Fiverr renders.
**The principle:** Verify market demand before building.
---
## Voice AI's Market Validation: Verify User Intent Before Building Features
**Traditional product development:**
```
1. Build voice navigation for entire site
2. Hope users want it
3. Discover: Users only want search and checkout voice control
4. Wasted effort on unneeded features
```
**Verification-first development:**
```
1. Capture user commands during demos
2. Identify top 5 most-requested actions:
- "Find product X"
- "Navigate to checkout"
- "Show pricing"
- "Compare plans"
- "Create account"
3. Build voice control for verified use cases first
4. Add features based on actual usage, not assumptions
```
**Verify demand before building.**
Just like Simon verified people would pay before manufacturing.
---
## The Customer Support Week: When Verification Happens In Production
Simon's delivery week:
> "I wake up to 25 customer support emails and by the time I'm done answering them, I get 25 more."
**The issues:**
- Bottom wires too short
- Knobs scraping
- Screwdrivers broken
- Screws wrong type
**Every issue = something not verified in manufacturing.**
**But Simon made it right:** Remade control tubes, shipped free replacements, responded to every email within minutes.
---
## Voice AI's "Customer Support Week": When DOM Changes Break Demos
**When website redesigns:**
- Button classes change
- Form fields reorder
- Navigation structure updates
- Session management changes
**Traditional automation:** Breaks silently, no one notices until customer demo fails.
**Voice AI:** Re-reads DOM, adapts to changes, surfaces ambiguity when uncertain.
**The difference:** Verification catches issues before customer sees failure.
---
## Murphy's Law Applies to Both Hardware and Voice AI
Simon's conclusion:
> "Anything not precisely specified and tested would without fail go wrong."
**Hardware failures from article:**
- Brightness tested at 39k lumens (not 50k) → Redesign power/heatsink
- Heatsink injection pins moved → Remade mold
- PCB pins mislabeled → Full day debugging
- Wire length not specified → Customer assembly issues
- Screwdriver quality not verified → Broken/dull tools
- Knob spacing not labeled in DFM → Knobs scraping
**Every failure = missing verification.**
---
## Voice AI Failures Without Verification
**If Voice AI didn't verify DOM state:**
- Click wrong button → Demo breaks
- Fill hidden fields → Silently fails
- Submit expired session → User logged out
- Navigate during modal → Action blocked
- Assume element exists → Element not found error
**Every failure = missing verification.**
**Both hardware and Voice AI share the same brutal lesson:**
**Verify explicitly, or fail silently.**
---
## Why "Ship Fast And Fix Later" Works in Software But Not Hardware (Or Voice AI)
**Software deployment:**
```
1. Ship feature with bug
2. Bug discovered in production
3. Rollback or hotfix
4. Users affected: some
5. Cost: low (server time, dev time)
```
**Hardware manufacturing:**
```
1. Ship 500 units with defect
2. Defect discovered by customers
3. Recall, remake, reship
4. Users affected: all 500
5. Cost: astronomical (tooling, shipping, reputation)
```
**Voice AI demos:**
```
1. Ship demo with broken navigation
2. Customer sees failure in real-time
3. Can't rollback (demo already failed)
4. Users affected: all prospects watching demo
5. Cost: lost deals, damaged reputation
```
**Hardware and Voice AI can't afford "ship and hope."**
**They require "verify then ship."**
---
## The Verification Hierarchy: Software → Voice AI → Hardware
**Level 1: Software (Forgiving)**
- Test coverage gives confidence
- Rollback possible
- Hotfixes cheap
- Users tolerant of bugs
**Level 2: Voice AI (Less Forgiving)**
- DOM verification required
- Rollback impossible (user saw failure)
- No hotfix mid-demo
- Users see failures in real-time
**Level 3: Hardware (Unforgiving)**
- Physical verification required
- No rollback (units already shipped)
- Recalls catastrophic
- Every unit must work
**As you move down the hierarchy, verification becomes more critical.**
---
## What Voice AI Learned From Hardware Manufacturing
Simon's 5 lessons map directly to Voice AI principles:
| Hardware Lesson | Voice AI Application |
|----------------|---------------------|
| **Plan way more** | Account for every DOM state, double edge case coverage |
| **Overspecify everything** | Verify element refs, no implicit selectors |
| **Test on many units** | Test on multiple page states and scenarios |
| **Visit suppliers early** | Test on live websites, not just staging |
| **Validate before commitment** | Verify user intent before building features |
**The meta-lesson:** Anything that executes in the real world (hardware, demos, production) requires verification-first architecture.
**"Ship and hope" only works when rollback is free.**
**When users watch you fail in real-time, verification isn't optional—it's survival.**
---
## Why Demogod Treats Demos Like Hardware Manufacturing
Simon's article reveals why Voice AI demos require hardware-level verification:
**Both execute in production:**
- Hardware: Physical units shipped to customers
- Voice AI: Demos run in front of prospects
**Both can't be rolled back:**
- Hardware: Can't recall 500 units cheaply
- Voice AI: Can't un-show a broken demo
**Both fail visibly:**
- Hardware: Customer sees defect immediately
- Voice AI: Prospect sees navigation failure immediately
**Both require explicit verification:**
- Hardware: Test lumens, measure dimensions, verify assembly
- Voice AI: Capture DOM, verify refs, check state
**Both are unforgiving of implicit assumptions:**
- Hardware: Unspecified = factory guesses = defect
- Voice AI: Unverified = agent guesses = broken demo
**The parallel is exact.**
---
## Conclusion: Verify First, Or Fail Later
Simon's hardware journey teaches the lesson Voice AI learned in production:
**Anything not verified WILL fail.**
- Didn't verify brightness → 39k lumens instead of 50k
- Didn't verify heatsink specs → Injection pins moved
- Didn't verify wire length → Customer assembly issues
- Didn't verify screwdriver quality → Broken tools
**Voice AI learned the same lesson:**
- Don't verify DOM state → Wrong button clicked
- Don't verify element refs → Navigation fails
- Don't verify session validity → User logged out mid-action
- Don't verify form state → Submission blocked
**Hardware taught Simon:** "Anything that can go wrong will go wrong."
**Production taught Voice AI:** "Anything not verified will fail."
**Both learned:** Verify explicitly, or fail silently.
**That's why Demogod captures DOM snapshots before every action.**
**That's why we verify element refs before clicking.**
**That's why we check session state before multi-step navigation.**
**Not because we're paranoid. Because Murphy's Law applies to demos just like it applies to hardware.**
**Verify first. Act second. Never guess.**
---
## References
- Simon Berens. (2026). [Lessons Learned Shipping 500 Units of my First Hardware Product](https://www.simonberens.com/p/lessons-learned-shipping-500-units)
- Brighter Lamp. [Product Page](https://getbrighter.com/)
- Brighter. [Indiegogo Campaign](https://www.indiegogo.com/projects/brighter-the-world-s-brightest-floor-lamp/)
---
**About Demogod:** Voice-controlled AI demo agents that verify DOM state before every action. One-line integration. Murphy's-Law-proof navigation. Built for SaaS companies who can't afford broken demos. [Learn more →](https://demogod.me)
← Back to Blog