Growth Summit Angola, registrations and access control
The back office of an invitation-only summit: approval based on available places, QR tickets by email and entry scanned on a phone, even without a network.
See it live backoffice.inscricao-gsa.comTeam-only access: the sign-in page is public.
An internal tool in daily use: only the back-office sign-in page is public. The event takes place on 13 and 14 November 2026 in Luanda.
01Problem
Growth Summit Angola is invitation-only, with limited places, and the Christian Growth Summit takes place the day before. Every request has to be read, then accepted or put on hold depending on the places left, and the rule is strict: anyone who registers for both loses both places.
On the day, entry has to be fast and reliable, even if the network at the venue goes down.
02Context
- Users
- The organising team (administrators and managers) and the accreditation staff at the entrance: three roles.
- Current process
- Registrations sorted one by one, lists cross-checked between two events, a paper list at the entrance.
- Constraints
- Limited places per event, two days, an unreliable network at the venue, the Angolan personal data law (Lei 22/11), no dedicated hardware at the entrance.
- Tools in place
- Public form
- Spreadsheets
03Solution
A custom back office connected to the public form: every request arrives with its reference and can be approved, waitlisted or declined, one at a time or in batches. The server will not go over capacity without explicit confirmation.
Every approved place generates a QR ticket, sent through an email queue that respects a sending rate, retries and keeps an exact copy of every message.
At the entrance, any phone becomes a scanner. The device stores the tickets as SHA-256 hashes, never the codes themselves: if the server does not respond, the phone decides on its own, queues the entry and syncs later, flagging any conflicts.
Why this approach. The weak point of an event is the door. An entrance that depends on the venue's Wi-Fi ends up as a paper list; an entrance that can work on its own never stops.
04Architecture
Input
- Public form Five-step registration, for attendees or press, sent to the back-office API with a unique reference.
- CSV import Imported lists with separator detection, a preview before anything is written, sent in batches of 400.
Interface
- Back office Dashboard, requests, records, duplicates, attendance, contacts, emails and settings, across three roles.
- Scanner The phone's camera: twelve verdicts with a beep, a vibration and a green or red screen; accessibility needs displayed.
Automation
- Rules and places Capacity per event, a three-criteria qualification score shared by the server and the interface, the double-registration rule.
Data
- API + SQLite Around fifty routes, 35 types of action in the log, screens refreshed every five seconds.
- Offline mode Tickets stored as hashes, a local decision if the server is slow, a queue of entries and a conflict report.
Output
- Email queue One QR ticket per place, a limited sending rate, three attempts, a pause option, an exact copy of every email.
- Attendance Arrivals in fifteen-minute slots, attendance rate, a printable A to Z backup list.
05Features
- Approval based on placesAccept, waitlist or decline, one at a time or in batches; going over capacity requires confirmation.
- One QR ticket per placeChange of holder, a new QR code to invalidate one that is circulating, manual entry and cancellation.
- Two events, one ruleQualification score, double registrations detected by name or email, a decision that is logged and reversible.
- The phone as a scannerNo app to install: the camera reads the QR code, the screen turns green or red, the phone vibrates.
- Entry with no networkTickets stored as hashes, a local decision, then sync and conflicts flagged when the network returns.
- Reliable emailsA queue with a sending rate, retries, pause, preview before setup and an archive of every send.
- Protected dataNewsletter export limited to people who gave consent, personal data erased on request.
- Traceability35 types of action in the log, including failed sign-ins and every export with its row count.
- Live figuresUpdated every five seconds, without ever interrupting someone in the middle of typing.
06Result
- Registrations are handled without a spreadsheet, within the places available for each day.
- Every approved place gets its ticket by email, and every send is archived.
- Entry keeps working if the network at the venue goes down.
How it is measured
- Time between request and decision
- Attendance rate per event
- Time to get through the entrance
07What I did
- Turning the event's rules into software
- UX/UI
- Back office in plain JavaScript
- Node.js API and SQLite database
- Scanner and offline mode
- Email queue
- Security and production launch