A working starter kit for event check-in and a live dashboard
A ready-made foundation that connects registration data with actual event attendance. It handles check-in at the door, keeps an aggregated dashboard updated during the event, and gives you an accurate view afterwards of who actually showed up.

At the first Women in AI Prague meetup, I didn't want to work from a registration list alone. At the door, I needed to find each person quickly, mark them as checked in, and at the same time see what the audience in the room actually looked like.
That led to a simple flow connecting registrations, check-in and a live dashboard. I turned the solution I used at my own event into a starter kit that another team can adapt to its own event.
The package includes a working demo mode, Google Sheets integration, Netlify Functions, automated tests, a security checklist and a ready-to-use brief for Codex or Claude Code. Instead of building from scratch, you start from a working foundation and adapt it to your own data, questions, branding and event flow.
How it works in practice
The starter uses one row per person. In your own version, you map the columns you use in your registration form.
They search for a person by name or email and mark them as checked in. If they make a mistake, the check-in can be undone.
On a public screen, you can show approved registration categories and their aggregated counts. The dashboard refreshes roughly every five seconds and does not send attendee names or email addresses.
The arrivals are marked in your Sheet, so you can separate everyone who registered from the people who actually came and continue working with an accurate attendee segment.
The cover image shows the real public dashboard from the first Women in AI Prague meetup. It displays aggregated categories and counts only, not attendee names or email addresses.
When this starter kit is useful
It is a good fit when you need to connect registrations, arrivals and a simple live view, but do not want to buy a large event platform just for that. For example:
- community meetups and networking breakfasts,
- internal learning days, workshops and company events,
- smaller conferences with a single check-in point,
- recurring events where the brand, venue or registration questions change,
- a pilot where a team wants to test its own flow before deciding whether it needs a larger solution.
The biggest time-saver is that you do not start from an empty folder. The architecture, demo flow, tests and basic security boundaries are already in place. Most of your time goes into mapping your own data, branding, and deciding how check-in should work for your specific event.
The same foundation can be adapted to another brand and a different set of questions. This is what the public aggregated dashboard for the EX Community Breakfast by BE-DNA looks like:

What the package includes
Once you unzip it, you will find two interfaces. The private check-in is for staff at the entrance. The public dashboard shows only approved categories and their aggregated counts.

The package includes:
- attendee search by name or email,
- check-in and undo for an incorrectly marked arrival,
- automatic synchronisation with Google Sheets,
- a live dashboard that refreshes roughly every five seconds,
- demo data and a sample CSV,
- a ready-to-use prompt for Codex or Claude Code,
- a technical specification, security checklist and automated tests.
The starter contains no production personal data, PIN, Google Sheet ID, service account key or third-party logo. The next team adds its own Sheet, column mapping, event details, branding and server-side environment variables.
How to hand it off to Codex or Claude Code
Add the unzipped folder to a new project and give the coding agent the AGENT_PROMPT.md file. The prompt first takes the agent through the README, technical contract and security rules. It then asks for specific inputs: event name, language, brand, Sheet, allowed registration statuses, dashboard categories and target hosting.
A key release boundary is also built into the brief: the agent should first prepare a local verification or a protected deploy preview. It should not change production without explicit approval.
I recommend adding only information that has already been confirmed. Do not put real keys or the PIN into the prompt. The agent should tell you exactly which environment variables to create and where to set them securely in your hosting environment.
A new security layer
The first version sent the PIN with every search and write request. In the current package, the PIN is sent only once to the server-side auth endpoint. After successful verification, a signed session is created and stored in a cookie with the Secure, HttpOnly and SameSite=Strict attributes.
In practice, this means:
- the PIN is not stored in browser storage,
- search and check-in no longer send the PIN,
- the session is tied to an allowed event ID,
- the absolute timeout can be set from 5 minutes to 8 hours,
- staff can log out manually,
- changing the session secret invalidates all active sessions,
- the auth route limits attempts to 5 within 180 seconds for each IP and domain combination.
Netlify notes in its documentation that rate-limit enforcement may begin after a short delay. That is why it is worth using a long event PIN and rotating both the PIN and session secret after the event. For a more sensitive or larger event, I would move to user accounts, SSO, roles and an audit log.
The public dashboard has a different data boundary. The endpoint does not return a name, email address or row number. Unknown responses are mapped to unspecified so the original text value is not exposed publicly. For very small groups, it is still worth considering a minimum aggregation threshold, because a combination of rare categories could indirectly identify a person.
Technical summary
| Layer | Use |
|---|---|
| Frontend | Static HTML, CSS and JavaScript for mobile check-in and a large-screen dashboard |
| Backend | Netlify Functions for authentication, session handling, search, writes and public aggregated data |
| Data | Google Sheets API, one row per person |
| Check-in protection | Server-verified PIN, signed HttpOnly cookie, timeout, logout and rate limiting |
| Public output | Allowed categories without names or email addresses; individual records are distinguished only by a short hash |
| Verification | Node tests, demo flow, JavaScript syntax checks and visual checks on desktop and mobile |
The automated tests cover data mapping, allowed registration statuses, handling people who share the same email address as separate records, check-in and undo, synchronisation with a simulated Sheet, session signing and timeout, and the absence of names and email addresses from the public API.
Once you add your own credentials, the real production flow still needs to be verified using an allowed test row.
Useful technical links
- Codex for developers
- Get started with Claude Code
- Netlify Functions – API and configuration
- Netlify rate limiting
- Google Sheets API
The starter is a foundation that needs to be adapted to the real event, its data and its risk level. If you would like to walk through your own use case, Sheet mapping or security boundaries, book a short intro call or email me at womeninaiprague@gmail.com.
Would you like to walk through your own event, Sheet mapping or security boundaries? Book a short intro call or email me at womeninaiprague@gmail.com.
Book a consultation