Blog › Build Story · Launch
The plan survived until
the first real checkout.
Launch day had a plan. The plan lasted until a payment path nobody had tested failed live. Here's the debugging, not the takings.
1
payment path nobody had exercised in testing
9pm
when the first failure showed up
1
person debugging it, solo
Same night
the fix shipped
Launch day, the plan, and the moment it stopped going to plan
Launch day had the usual shape: a checklist, a monitoring tab open, and a quiet confidence that the weeks of testing beforehand had covered the things that mattered. Signups came in. The product worked. For a good stretch of the evening, it looked like the unremarkable kind of launch every solo founder secretly hopes for.
Then a message came through from someone stuck partway through checkout. Then another, following a slightly different path to the same point. That's the moment a launch stops being a checklist and starts being a live incident.
What broke: a payment path nobody had hit in testing
It wasn't the core payment flow - that had been tested thoroughly, repeatedly, from every angle I could think of. It was a specific sequence through checkout, one particular combination of steps a real person took that none of the test scenarios had happened to cover. The kind of path that looks obvious in hindsight and invisible beforehand, because it only exists at the intersection of a few otherwise-fine decisions.
Debugging it solo, at night, with customers waiting
There was no on-call rotation to escalate to and no support team to buy time while someone else looked at the logs. It was one person, one laptop, and a growing sense that every minute spent understanding the problem was a minute someone else was stuck staring at a spinner. I traced the failure back through the logs, reproduced the exact sequence that broke it, and worked through the fix in real time rather than waiting for a calmer moment to think it through properly. There wasn't a calmer moment coming.
The lesson wasn't "test more." It was "launch with a way to fix things fast."
What I changed immediately afterward
The fix that night was necessary but not sufficient. In the days after, payment paths got their own monitoring, separate from general uptime checks, specifically so a failure like this would surface as an alert instead of as a message from someone stuck at checkout. The bar for "that edge case is probably fine" dropped considerably. If it's on the payment path, it gets tested before launch, not discovered after.
What this taught me about launching solo without a support team behind me
Launching solo means there's no one to hand a problem to while you think. The response time is whatever your own attention allows, which is faster in some ways than a team with a process to follow, and much more fragile in others - there's no second pair of eyes, no backup if you're asleep or offline. That trade-off doesn't go away by wishing for a team. It gets managed by building the monitoring and the fixing speed a solo operation actually needs.
Why I still think launching imperfect beats waiting for perfect
No amount of pre-launch testing would have found this particular path, because it only exists once real people start using a product in ways you didn't fully anticipate. Waiting for "fully tested" before launching is waiting for a state that doesn't actually arrive. The honest goal isn't zero problems on launch night. It's the ability to notice a problem fast and fix it fast, which is exactly what let that night end with a shipped fix instead of an open incident.
Quick answers
What actually broke on BrandSwitch's launch day?
A payment path that nobody had exercised in testing - a specific sequence through checkout that worked fine in every test scenario but failed the moment a real person on a real device followed it live.
How was it fixed?
Solo, at night, by tracing the failure through logs in real time, reproducing the exact path that broke, and shipping a fix the same evening rather than waiting for a scheduled release window.
What changed after that night?
Monitoring on payment paths specifically, not just general uptime, and a much lower bar for treating a 'probably fine' edge case as worth testing before it ships, not after.
Is launching without everything tested a bad idea?
Not necessarily. The real requirement isn't a perfect launch - it's the ability to notice a problem and fix it fast when something breaks, because something almost always does.
The product that survived launch night
BrandSwitch shipped that fix the same night and kept going. The messiest part of any launch is rarely the product itself - it's everything wrapped around getting someone from interested to paid, and having a way to fix it fast when that path breaks.
See the product that survived launch night
Built solo, tested hard, fixed fast when it needed to be.