Et manipulationssikkert lodtrækningssystem til en tankstationskæde: 16.000 deltagere, ingen app at downloade

Kunden kom til os med et mål, ikke en kravspecifikation: at belønne kunderne med lodtrækninger på flere stationer. Hvordan det skulle fungere, var op til os.

Det lød som en formular: kunderne tilmelder sig, og nogen trækker en vinder. Da vi gravede i det, viste de reelle krav sig at være sværere:

• Kun rigtige kunder skulle kunne deltage. En deltagelse skulle være knyttet til et faktisk besøg på en station, ikke til et link delt i en gruppechat.
• Personalet er ikke teknisk. Ekspedientens del skulle klares med ét tryk.
• Kunderne installerer ikke noget. Ingen app, ingen konto.
• Der skulle være tillid til det. En lodtrækning virker kun, hvis folk tror på, at den er fair, så den skulle være svær at snyde og nem at revidere.

Det var ikke en formular. Det var et integritetsproblem.

Ét system, tre roller.

1. 01Ekspedienten åbner appen på sin telefon og trykker én gang. En QR-kode dukker op, gyldig i fem minutter. En dagstæller viser, hvor mange deltagelser ekspedienten har genereret.
2. 02Kunden scanner den med sin egen telefon og udfylder en kort formular, der valideres i realtid. Ingen download, ingen tilmelding.
3. 03Administratoren styrer stationer, lodtrækninger og ekspedienter, følger deltagelsen på et dashboard med KPI’er, grafer og en søgbar deltagerbase og gennemfører selve lodtrækningen.

• Engangstokens, der udløber. Hver QR-kode indeholder et SHA-256-token, der udløber efter fem minutter og forbruges atomisk, så det hverken kan genbruges eller forfalskes.
• Adgangskontrol på to niveauer. Rollebaseret routing for administratorer og ekspedienter plus PostgreSQL Row Level Security på et skema med 8 tabeller, triggere og funktioner.
• Hærdede offentlige endpoints. Rate limiting og Zod-validering på alle API-ruter, der modtager kundedata.
• Testet før lancering. Unit- og integrationstests med Vitest.

Da en enkelt lodtrækning passerede 1.000 deltagere, blev dashboardet ved med at vise præcis 1.000. Årsagen var Supabases standardgrænse for, hvor mange rækker en forespørgsel returnerer. Vi flyttede optællingen ind i en PostgreSQL-funktion, der aggregerer på serveren og returnerer én række pr. lodtrækning i stedet for hver eneste deltager. Vi validerede det lokalt og sendte det derefter i produktion.

Leverancen omfattede en demo på stedet, en brugermanual og et overdragelsesdokument.