Kilogbede Records needed to sell real tickets to a real show through eventOS. Not a staged run-through. A stranger, a card, and a ticket that had to actually work at the door.
That is a different bar from "checkout works in a demo." A demo forgives things a paying customer never will.
The gap between working and trustworthy
By the time this started, eventOS could already walk someone through picking a ticket, paying for it, and getting a confirmation. Every individual screen worked.
What hadn't been proven yet was the thing that only shows up under real pressure: that every step in that chain agrees with every other step, at every moment, including the moments nobody planned for. A price shown on a screen has to be the same price the system actually charges. A ticket confirmed has to be a ticket that scans. A sale that opens has to open exactly when it's supposed to, and nowhere it isn't.
None of that is visible in a walkthrough. It only becomes visible when something goes slightly wrong. And something always does, eventually.
Deciding what "ready" meant before opening the doors
Rather than trust that the pieces already built would hold together under real load, we treated "ready for a real customer's money" as its own checklist, separate from "the feature exists."
A few decisions came out of that:
The system that owns pricing and inventory decides when a sale is open. Not the page showing it. A storefront can be told a sale starts at a certain time, but the page itself should never be the thing deciding whether to accept money. If a sale is supposed to open at 9am, the source of truth for tickets has to be the one enforcing that, so there's no window where a link or a cached page lets someone buy early or after the fact.
Before turning on real payments, we walked every step a paying customer would take and checked that each one honored the same rules the storefront was about to promise. Not "does the button work," but "does the price the customer sees match the price that gets charged, does a successful payment reliably produce a valid ticket, and does a failed payment reliably produce nothing." Those three questions sound obvious. Answering them honestly, under time pressure, before a real sale opens, is the actual work.
Anything a customer uploads is treated as coming from them, not from us. Even after it's stored. Ticket artwork gets uploaded by the organiser, not written by the platform. Content that originates outside the system doesn't get the same trust as content the system generated itself, no matter where it ends up living afterward.
The bug we caught before a customer found it
While we were still in that readiness pass, we found a real one: a customer could start checkout on one device and finish paying on another. A common pattern when a purchase hands off to a banking app. The confirmation logic needed to recognize that as the same purchase, regardless of which device came back asking for the result.
Get that wrong and the failure mode is quiet and bad: a customer pays successfully, but the device asking "did this work?" doesn't recognize the answer, and they're staring at an unclear state for a transaction that actually succeeded. Nothing crashes. Nothing errors. It just looks broken at the exact moment someone is holding a receipt for money they already spent.
We caught it during the readiness pass, not after a real customer hit it. That's the difference the checklist was for.
What shipping it actually meant
The sale went live. Real people paid real money and got real tickets. From the outside, that looks like flipping a switch.
From the inside, it was closer to: decide who is allowed to say a sale is open, prove every step in the money path agrees with itself before trusting it with someone else's money, and go looking for the failure that only shows up when two devices disagree about the same transaction. Before a customer finds it for you.
That's the part of "launch" that doesn't show up in a demo.