The demo works. It's always worked, for weeks now, if you walk through it the normal way -- pick a slot, enter your details, verify, pay, done. The happy path is smooth. And the happy path is a liar, because almost nobody walks the happy path exactly. Real people arrive tired, distracted, on bad wifi, with fat thumbs and second thoughts. Today's job was hunting the edge cases -- all the weird, ugly little situations where a booking quietly falls apart -- because that's where the real world lives, and it's where a product either earns trust or loses it.
The scariest one I chased is the double-booking race. Picture two guests, both looking at the same open slot at the same moment, both hitting "book" in the same second. Naively, the software says yes to both -- and now one time slot has two people who each think it's theirs, one of whom is going to show up to a very awkward situation. This is a genuinely hard problem because it's about timing, not logic; both requests look perfectly valid on their own. The guard I built for this -- a grace-period check that stops the second booking from sneaking in while the first is still settling -- is the kind of thing you only find out works by deliberately trying to break it. So I did. I hammered the same slot from two directions and made sure exactly one booking wins and the other gets a clean "sorry, just taken." It holds. But I had to prove it holds, because "probably fine" isn't good enough when it's someone's calendar.
Then the small, human, un-dramatic ones -- the paper cuts:
What happens when a guest fat-fingers their email at the OTP step? They typo one letter, the code goes to an address that isn't theirs, and now they're staring at a "enter your code" screen with no code coming. Does the product leave them stranded, or does it let them fix it and try again gracefully? It has to be the second one.
What about past-time slots -- does the system ever let someone book a time that's already gone? What about a fully-booked day -- does it fail cleanly and clearly, or does it show a confusing empty void? What about a host who toggles a service off while a guest is mid-checkout on it -- what does that poor guest see? Each of these is a tiny, specific moment where a real person could hit a wall, and each one, left unhandled, is a booking that dies and a person who quietly decides your product is broken.
None of these are glamorous. Not one of them will ever be a feature I announce. Each individual fix is almost embarrassingly small. But here's the thing I keep coming back to: together, they are the entire difference between trust and a refund request. A product isn't judged on its happy path -- everyone's happy path works. It's judged on what happens the one time something goes sideways for you, personally. If it catches you gently, you trust it forever. If it drops you, you never come back, and you tell people. The edges are where reputation is actually made.
And the whole reason I'm grinding through these now, alone, before launch, is simple: I would much rather find these than have Yukta's patient find them. Every edge case I catch today is a small humiliation for me in private instead of a broken booking for a real host in public. Finding your own bugs is cheap. Letting your first real customer find them is the most expensive thing there is. So I sat here today and tried, deliberately, patiently, to be the worst, clumsiest, unluckiest user my own product has ever seen -- so that the real ones never have to be.
It's tedious. It's invisible. It's exactly the work that makes something feel solid instead of fragile. And it's almost done.
Tomorrow, the screen I've been dreading more than any bug: the pricing page. The one I end up rewriting five times.
Explore more from Shubham — discover curated reads at BookASloth, or check out Rajmudra Media for media & marketing solutions.
Explore more from Shubham — discover curated reads at Book AS loth, or check out Rajmudra Media for media & marketing solutions.