Section C2 · From kitchen table to roadworthy
The last mile
The demo takes an evening. The product takes a season. Nobody tells you this at the start, so the manual is telling you now: several of us have independently discovered that the last ten percent of a build is where most of the hours, and nearly all of the shouting, live. This page is why, and what to do about it.
Why the demo is easy
A demo only has to work once, for you, on your machine, on the happy path. Modern AI tools are spectacular at this. You describe the thing; a working version appears; the family is impressed. That part is real, and this manual encourages it without reservation.
Why the product is hard
A product has to work every time, for strangers, on their machines, on the paths you never imagined. That is a different job. It is not that the AI gets worse at the end; it is that the end is made of things which are unforgiving of guesses: login systems, domain records, email delivery, other people's data. One of us spent twenty hours across two months on sign-in alone. Another got a working tool adopted by his team in a week, then discovered that making it official meant security reviews, support rotas and a handover document. Both were doing it right. The wall is real.
The six things that have to be true
- People can get in, reliably. Sign-in is the single most common place builds die. Magic links expire, codes arrive malformed, sessions drop. Use the most boring, most standard option your platform offers and resist inventing your own.
- It lives at a proper address. A real domain, correctly pointed. DNS is simple but merciless: one wrong record and everything mysteriously half-works.
- Its emails actually arrive. Sending is easy; arriving is not. Use an established sending service, verify your domain, and never send from a personal address: nothing kills trust faster than a hobby email on a serious product.
- Other people's data is safe. The moment a stranger types their details into your thing, you have obligations: sensible storage, backups, a way to delete on request, and honesty about what you keep.
- Someone can fix it at 9pm. Logs you can read, errors that say something, and notes future-you can follow. If only the AI understands how it works, nobody does.
- Someone carries the can. Terms of use, clear wording about what the thing is and is not (an opinion, not advice), and a think about what happens if it is wrong. The machine has no professional insurance. You do, or you should.
The rules of thumb
Budget ten times the demo time to reach strangers-can-use-it. Ship the boring version first. Test the unhappy paths on purpose (wrong password, dead link, empty form). And know when to stop doing it yourself: the point where DIY stops being a saving is usually somewhere between items 3 and 6 above, and paying a professional for exactly those items while keeping the rest is not defeat, it is engineering.