A lucky draw platform that runs in front of a room full of people.

The problem

Most software gets to fail privately. Someone hits an error, reloads, and moves on. An event lottery does not have that option. It runs once, on a projector, in front of several hundred people, and a spinner that hangs for ten seconds is a story the company tells for years.

The functional requirement — pick a random name — is trivial. Everything hard about this project is about what happens around that one line.

What the system does

• Attendee management — importing and correcting the guest list before the event, which is when the list is always wrong and always changing.
• Prize tiers — multiple prize levels drawn in sequence, with rules about whether a winner can win again.
• Public draw animation — the screen the audience sees, built to read clearly from the back of a room rather than at desk distance.
• Operator control — a separate view for the person running the draw, so nothing meant for the operator ever appears on the projector.

How it is built

Laravel handles the data and the draw logic; Tailwind and JavaScript handle the presentation screen. The architecture is shaped almost entirely by the fact that the event happens live.

The winner is decided before the animation starts

The draw is resolved on the server first and recorded, then the animation plays out a result that already exists. Doing it the other way round — animating and then asking the server — means a network hiccup can leave a spinning wheel with no answer, in front of an audience. Deciding first turns a potential failure into, at worst, a slightly shortened animation.

Two screens, one state

The operator view and the audience view are deliberately separate surfaces over the same state. It removes an entire category of embarrassment — no dialogs, no admin controls, no error toasts on the projector.

Designed to be read, not admired

Names render large, with high contrast and generous spacing, because the real display is a projector in a bright ballroom, not a laptop in a dark room. A lot of event software is designed at desk distance and fails at the only distance that matters.

What I would change

The draw rules — who is eligible, whether previous winners can win again, how tiers interact — were built as code rather than configuration. Making them editable by the event organiser would have removed the need for a developer every time an event ran with slightly different rules.

Need something similar?

Live displays and event tooling need different engineering priorities than internal systems. The services page covers the range I take on, including applications with a public-facing surface.