Nobody Said Take My Money — Part 3 of 7
If you’re an engineer, this is the post that will read most like a mirror. It’s about the year I spent building Mother Hen, why that year felt productive the entire time, and why the feeling was a lie.
What got built
I’ll keep the inventory short because Part 1 already ran it, but the shape matters. Over roughly fourteen months, one person — me — built:
A four-device embedded product line from a single firmware codebase: a cellular coop controller, a WiFi variant, an egg-shaped status light, and a multi-coop display, compiling to four binaries with about 70% shared code, on ESP32 hardware under ESP-IDF and FreeRTOS. Cloud provisioning, so a device could be drop-shipped and come alive without any in-field pairing ceremony. Over-the-air updates with rollback protection. A backend of 34 Lambda functions, including a risk engine that classified every event into four severity tiers with day/night context and adaptive grace periods. A customer web portal. A versioned alarm specification governing exactly when a customer got woken up and why. Two patent filings. Product liability insurance. Legal pages, SMS compliance registration, a subprocessor list.
None of that is padded. It all worked. The system ran for months at two beta sites, one of them 1,500 miles away, and it did not embarrass me once.
Now the other column. Over the same fourteen months, the number of demand tests run — tests capable of producing the answer “no one will pay for this” — was zero, until the very end, when three of them arrived in quick succession and all said the same thing.
The seduction
Here’s the mechanism, as honestly as I can reconstruct it.
Every engineering problem has a property that makes it psychologically wonderful: it can be solved. The modem won’t hold a session — you debug it, and it holds. OTA updates might brick a remote device — you build rollback protection, and they don’t. Each solved problem produces a real, verifiable increment of progress. The system genuinely is better today than yesterday. You can see it in the commit log.
The market question has the opposite property. “Will strangers pay for this?” cannot be solved at the workbench. It can only be asked, out loud, of people who owe you nothing, with a real chance the answer is no — and a no doesn’t come with a stack trace. There’s nothing to fix afterward. It’s just a no.
So a competent builder, given the choice each morning between a task that reliably produces progress and a question that might end the project, will pick the task. Every time. And call it discipline.
That’s the part I want to name precisely, because “I procrastinated on marketing” is not what happened. What happened is that competence generated its own momentum. The better the engineering went, the more real the product felt, the more absurd it seemed to question whether it should exist. Working code is rhetorically powerful — it argues for itself, and it argues to you, its maker, hardest of all. Nobody looks at a fleet of devices self-provisioning over cellular and thinks “I should check whether this is a business.” You think: “this is a business, look, it works.”
Working is not the same as wanted. I knew that in the abstract. Everyone does. The year of building is what it looks like to not know it in practice.
The tell in the roadmap
If you want a diagnostic you can apply to your own project this afternoon, here it is. Look at your roadmap and sort every milestone into two piles: build gates — things that block on engineering (“PCB spin 2 back from fab,” “solar power validated,” “OTA rollout tooling done”) — and demand gates — things that block on strangers paying (“five pre-orders in hand,” “first paid conversion from a cold audience”).
My roadmap was all build gates. Hardware revisions, sensor additions, a solar power workstream, certification work, feature specifications. At one point, late in the venture, sales were formally suspended pending an engineering effort — the purchase page taken down until a power subsystem was ready, an estimated four months out. Read that back slowly: the demand question was still unanswered, and the thing standing in front of it was an engineering gate. I had, without ever deciding to, built a structure where no market evidence could interrupt the building.
Not one milestone, in fourteen months, said “N strangers have paid.” That’s the tell. If your plan has no demand gate before the next build gate, your plan is a bet that the market question will answer itself. It never does. It just waits, with the meter running.
What the meter said
The full-numbers policy of this series applies to the uncomfortable parts too.
The cloud infrastructure cost almost nothing — $1 to $7 a month in AWS, total, for the whole platform. Engineering time was the real spend, and I was doing it solo, so the ledger shows opportunity cost more than cash. But the cash wasn’t nothing: in one 89-day stretch near the end I tracked it precisely, and one-time hardware and booth spending came to about $6,400 — components, enclosure fabrication runs, festival booth — against a self-imposed $2,000/month ceiling that the hardware months blew through. Two patent filings and their fees. Product liability insurance at $77/month. All of it spent ahead of the first datum about whether a stranger would pay.
None of those individual purchases was wrong. Every one of them was wrong in that order. Each dollar was a build-gate dollar spent while the demand gate stood unexamined at the front of the line.
The lesson, made runnable
Development milestones are not evidence. They feel like evidence — each one is real, verified, done — but they are evidence about the product, and the open question was never the product. The open question was the market, and no quantity of build progress bears on it at all.
The runnable version: put a demand gate in front of every expensive build gate, and write it down before you start. Before the second PCB spin: some number of deposits. Before the certification spend: some number of pre-orders from strangers. Before the patent filing: a channel partner who has said yes in writing. If the demand gate fails, the build gate doesn’t open — no matter how clear the engineering path looks, and it will look clear, because engineering paths always do. That’s what makes them such a comfortable place to hide.
I built a system that never had an outage that mattered. The business had exactly one outage: nobody bought anything, ever. I spent fourteen months monitoring the wrong system.
Part 4: Three Tests, One Answer — Enthusiasm Is Not Demand. The post where this series earns its title.