The Wrong Address Variant Nobody Had Typed Until Launch Week

Forty-eight hours before anything worked, our whole operation was two people, a loose plan, a shared folder full of notes, and a running conversation.

Everything about the idea felt real when we talked about it. None of it was real in the way a business needs: something either of us could log into, use, and trust would still be there tomorrow. Decisions were living in conversation. What each of us did next depended on remembering what had been said out loud.

The shared folder lost

My first move was to make the shared drive the center of the operation. We kept it, and it stayed useful for deeper documents and the long-term plan. But it lost as the daily working surface for one simple reason. A folder can’t tell you what to do next. It just holds whatever was put into it last.

The second idea was an ordered checklist. It looked better on paper and was wrong for the moment we were in. Two people don’t start a venture from the same place, and a fixed sequence made the workspace feel like a form to fill out instead of a place to think. We threw it out and rebuilt it as a set of areas either of us could work on from wherever we actually were.

A boring test instead of a demo

Once decisions needed a real home, a static page of notes wasn’t enough. It had to be something we could write to and trust to hold what we wrote. So we defined the test for “does this work” narrowly, almost boringly: sign in, add a decision, reload the page, and see that it’s still there. We ran it on the real site, not a preview.

That short sequence touches every part that has to work. It checks who is allowed in, whether a write really saves, and whether what comes back on reload matches what went in. A polished screenshot skips all three questions. This test couldn’t.

What the boring test caught

It wasn’t a formality. After a visual redesign, the site looked finished on a desktop screen and showed a broken, unusable page on an actual phone. A screenshot review would never have found that. It turned up only because someone opened the real site on a real phone and looked.

A second problem surfaced the same way. One address for the new site worked perfectly, while a closely related one returned an error nobody had checked. It wasn’t a feature bug, but it would have embarrassed anyone who happened to type the wrong version.

What still needed a human call

None of this settled the business questions. What to charge, whether the offer was right, how much to trust each other’s early instincts: none of that came from a working login screen. What the working system bought us was speed between having an idea and seeing whether it held up against the real thing.

A venture becomes real the day both people responsible for it can come back, see what was decided, and trust that the record is still there. Before we call anything finished now, we run the same short test on the real site: sign in, add a record, reload, confirm it’s still there. Then we open it on a real phone and try each address variant.

dxdev LESSON · paste into your AI coding agent
LESSON: Define "shipped" as the smallest sequence that crosses every real boundary, then run it live
SOURCE: dxdev.com/blog/venture-from-idea-to-domain-in-two-weeks
WHAT HAPPENED: Two founders needed their new venture's decisions to live somewhere real instead of scattered across documents and conversation. The acceptance test for the first working feature was defined narrowly on purpose: sign in, add a decision, reload the page, confirm it's still there, and run that exact sequence on the live production site rather than a preview. That discipline caught two real problems a polished demo would have hidden entirely: a visual redesign that looked shipped on desktop but showed a broken white page on an actual phone, and a working subdomain that masked a separate broken address still returning an error.
THE RULE: Define the acceptance test for any new feature as the smallest sequence that crosses every real boundary it touches, sign-in, the actual write, the real data store, the page a person would actually see, rather than the sequence that produces the best screenshot. Run that test against the live target before calling anything shipped, not a preview standing in for it.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any feature marked shipped or verified from a preview or staging environment alone, without the same sign-in-write-reload-confirm sequence also run against the live production target.
  2. Any interface change verified only on one device type, when real users will hit it from more than one.
  3. Any newly launched address or route verified for its main path only, without checking the adjacent ones sharing the same setup.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.