We audited our own booking flow

The scariest bugs in a booking system are not the ones that crash. A crash is loud; someone notices; you fix it. The scary ones are the quiet mismatches — a payment marked paid that never confirmed, two people holding the same slot, a number that is off by a rupee in a place nobody checks. So before leaning harder on real money, we sat down and audited our own booking flow against the live database, on the hunt for exactly those.

It is an uncomfortable thing to do on purpose. You are reading your own code with the assumption that it is lying to you, checking the parts you were proudest of first, because pride is where you stop looking. But it is the only honest way to earn the sentence 'you can trust us with the money,' and that sentence is the whole product.

What held

The core held, and it held for good reasons rather than luck. Two people cannot end up in the same slot, because the database itself refuses to store overlapping bookings — the guarantee lives in Postgres, not in hopeful application code that a race condition can slip past. A payment is captured exactly once, because every path that could mark a booking paid funnels through a single winner-takes-it step. And pricing is snapshotted at the moment of booking, so what you were charged can never drift because a setting changed later.

That last point is worth dwelling on, because it is the difference between a booking system that works in a demo and one that works on a busy Friday. When fifty people try for the same slot at once — which is not hypothetical for a popular host — the winner is decided by the database, once, and the other forty-nine get a clean 'taken,' not a double-booking to apologise for on Monday.

What we found to fix

It was not a clean bill. The audit turned up a stack of things worth fixing — none catastrophic, several embarrassing. A paid-but-unconfirmed booking had no automatic second attempt to nudge it over the line. A cancelled paid booking did not raise a flag for a refund. A reminder cron, under the wrong timing, could double-send. None of these were on fire; all of them were the kind of quiet wrong that erodes trust one small confusion at a time.

The value of writing them all down — with a severity next to each, verified against the real database rather than assumed — is that a list you can see is a list you can burn down. Deferred work that lives only in your head is deferred forever. Deferred work with a number next to it is a plan.

Read your own code as if it is lying to you, and check the parts you are proudest of first. Pride is exactly where you stopped looking.

The bit worth keeping

We publish this for the same reason we publish the security work nobody claps for: a thing written down in public is a thing you can be held to. The booking flow is sound where it counts, honest where it is not yet perfect, and the not-yet-perfect list is short and shrinking. That is the most truthful thing we can say, and we would rather say it than a slogan.