Teaching a gift card platform to sell a club night

Kuvert began as gift cards for restaurants. Tickets came next, because a restaurant that sells a gift card also hosts a wine evening, and then table booking, because a restaurant that sells tickets also takes reservations.

Then Club Vortex, a nightclub in Vejle and one of our clients, switched table booking on and got a restaurant's calendar with nothing on any day. It was a fair result. The product was doing exactly what it had been built to do for somebody who was not a nightclub.

A club sells the night#

A restaurant's evening is opening hours cut into times, a table held for a duration, and a guest who may change their mind. A club's evening is one night, sold in advance, and the tables are not reserved for 19.30. They are booths, sold as packages with the night: a table for six, with a bottle, from when you arrive.

So nightclub mode is not a second booking engine. It is a front door onto the event system Kuvert already had. A table package is a ticket price for more than one person, attached to a night. The club's booking page lists the nights on sale that have packages, and choosing one opens that night with the package in the basket. The same checkout, the same receipts, the same door.

The booths have names, because a club's staff do not say "table 7". The floor editor lets the club draw its room and name its tables as they are known inside the building, and a guest picks a booth on that map before the package.

One release at a time#

Clubs sell tickets in releases. Early bird first, then first release, then second, each a little dearer than the last, and the next one opens when the one before it sells out.

The first version let a club put several prices on sale at once and left the order to the club. While setting up Club Vortex's test shop, a special night had Early bird and first release on sale side by side, so a buyer could pick the dearer ticket right beside the cheaper one. Nobody would ever do that on purpose, and the page was offering it.

Now a price can name the release it waits for. It stays closed until that one sells out or closes, or until its own opening date arrives, whichever comes first. The rule lives in one pure function that the event page, the price quote, the checkout and the waitlist all ask, so none of them can disagree about what is on sale. It survives the ways a club reuses a night, too: duplicating a night, a weekly series and a saved setup all carry the order with them, and deleting a release in the middle joins its neighbours instead of leaving a price waiting for something that no longer exists.

The door#

The screen that matters most on a club night is the one nobody chose to use: a phone at the door, held in one hand, in the dark, with a queue.

The scanner's own source had a comment saying that making staff tap once per guest was the wrong trade. The code underneath it did exactly that. Every verdict froze the camera, and it only started again when somebody pressed "Scan next". For a club letting a few hundred people through one door, that is a few hundred taps.

The fix was to separate two kinds of answer. A gift card opens a transaction: somebody has to enter an amount and finish it, and it must not be replaced under their thumb. So a gift card still holds the camera. A ticket's verdict is final: green, let them in, next. So the camera keeps running and the verdict stays on screen until the next ticket replaces it.

That made a second problem visible. The scanner had a short cooldown after reading a code, tuned for a card lying still under a lens. A guest who holds their phone up for three seconds while they look for their friends is past it, so the same ticket fired a second check-in and the screen flipped from a green admit to "Already used", about somebody who had just been let in. A longer cooldown is not the fix, because any number is a guess that also makes the next guest wait. The rule is simpler: whoever is on screen is the person in front of you, however long they take, so a camera frame showing the ticket already on screen is ignored. Typing a code by hand is exempt, because that is staff asking on purpose whether a ticket has been used, and when.

And underneath both was an older bug: the scanner re-armed every time a request finished. A lookup that failed put nothing on screen, so the same code was read again a fraction of a second later, failed again, and so on, as a tight loop of failing requests on a phone that was by then usually failing because it had no signal. The scanner now re-arms only when staff say they are finished with a guest, which is not the same event as a request coming back.

Test mode first#

Club Vortex is setting up in test mode as I write this: its own nights, a release ladder, a weekly club night that puts itself on sale, a gift card and its tables, all in a copy of the shop that takes no real money. A script builds that copy, so anyone can read exactly what the club's setup is, and run it again.

The lesson I keep relearning on Kuvert is that every new kind of business shows up with an assumption the product never knew it had made. A restaurant taught it that a gift card is spent in pieces. A club taught it that an evening is not a list of times, and that the most important screen is the one used with one hand in the dark.