Most organizations have a few processes that only work, because staff have learned how to work around the limitations. At one organization I worked with, event operations was one of those areas.
The organization hosted a couple of conventions every year and the website handled the event registration: attendees picked the type of pass they wanted to buy, selected sessions, provided badge information, and paid for the convention. After registering, they received a receipt and confirmation showing the pass they chose and the sessions they selected.
The system also supported important event rules. Registrations had open and end dates so staff could handle badges and logistics, and sessions had seat limits so registration could stop once a session reached capacity.
On the surface, the registration process worked. But the operational side after registration still involved a lot of manual work.
01Where the manual work showed up
Before each convention, staff exported the attendee list, printed everyone’s badges, and mailed them to the convention location. At the event, staff verified each attendee’s ID and handed them the badge. It worked, but it was a slow manual process for staff.
Recording session attendance was even more cumbersome. Some sessions offered continuing education credit, but credits were only supposed to be awarded to attendees who actually attended the session — not just people who registered for it.
Staff used sign-in sheets to track attendance. After the convention, they manually updated the database through the user interface with the attendance data they collected. Because of that manual process, there could be up to a 45 day delay before attendees had access to their CE credit certificates.
02Why we decided to build something
At a certain point, the organization made the decision to improve the process and started looking at vendors. Most of the quotes we received were around $15,000 for every event where we would use the vendor’s services, which was cost-prohibitive.
I had been pitching the idea of automating this process in-house for a while. But for nonprofits, especially smaller nonprofits, this is not always easy. Many do not have in-house development teams, and even when they do, those teams are usually working on many other priorities at the same time.
However, due to the estimated cost-savings and after my reassurance that it was feasible to do in-house, my team and I were given the opportunity to take on the project.
My goal was simple: reduce the amount of manual work staff had to do, make things as fast and real-time as possible, and most importantly, avoid creating any kind of friction that would cause staff to revert back to the old way of doing things.
03Understanding the requirements
We had a high-level understanding of the process, but we still needed to understand the details. In smaller nonprofit environments, people often wear multiple hats. There was no dedicated business systems analyst to gather requirements for us, so we had to do that work ourselves.
We met with the database team to understand how events were set up in the system and what nuances existed. We also connected with the events and marketing teams to understand what they expected, what they controlled, and where the current pain points were.
That helped us shape a plan that focused on the real event workflow, not just the technical side of the project.
04The plan
The core idea was to use a QR code that could support multiple workflows.
When an attendee registered on the website, the system would generate a QR code and include it in the confirmation email. We also wanted to send a reminder email a few days before the event so the QR code would be easy to find at the top of the attendee’s inbox.
That QR code needed to do a lot. It represented a GUID that already existed in the system and was tied to the registration ID. It allowed the attendee to print their badge, appeared on the printed badge to allow staff or temporary staff to scan attendees into sessions for CE credit, and allowed attendees to scan the QR code with their own phone to see the sessions they registered for.
We also wanted the same badge QR code to support exhibitor lead tracking. Exhibitors registered through a third party, but we handled badges and event logistics. Building lead tracking into the Events App would add value for exhibitors and remove the need for paper sign-up sheets at their booths.
The bigger goal was to build a portal where staff could easily manage event attendees and exhibitors. Our backend system was netFORUM, but we did not want staff working directly inside netFORUM during the event. We wanted to bring the important event data into a simplified portal where everything was at their fingertips.
We also introduced badge design features and different badge options for guests, first-time attendees, students, regular attendees, exhibitors, and staff.
05How we built it
We knew we needed an intermediary database because we did not want thousands of calls hitting netFORUM on event day. That would create unnecessary risk during a high-pressure event workflow.
The intermediary database also helped us avoid storing thousands of QR code images inside netFORUM when those assets could be managed more cheaply elsewhere.
We needed our own subdomain and wanted to use the same authentication as the website so staff would not have to remember another username and password. For exhibitors, we originally wanted to avoid a password and make login as simple as possible with a link-based sign-in.
We also needed actions to happen automatically when things changed. When someone registered, the system needed to get event data, get registrant data, generate the QR code, store it, update the right records, and send the confirmation email.
For this type of system — something that needed to scale during events but was only heavily used a few times a year — Firebase made sense. It had all the elements we were looking for: a fast database, affordable storage, cloud functions, and authentication flexibility without managing a lot of infrastructure.
We chose Next.js for the frontend because it is a popular modern framework and gave us a strong foundation for building the staff portal and event workflows. We also used Sentry for error tracking so we could monitor issues more effectively.
06How the system worked
When an attendee registered on the website, the registration and payment were still processed through netFORUM and it remained the source of truth.
As part of the confirmation process shown to the attendee, the registration ID was saved to Firebase Firestore. A cloud function then checked whether it had the needed event data, pulled the registrant data, generated the QR code, saved it in Firebase Storage, and updated the QR code location in Firestore and netFORUM.
Another cloud function handled the confirmation email, which included the attendee’s QR code.
From there, the Events App became the operational layer for the event. Staff could look up attendees, print badges, reprint badges, update badge information, scan attendees into sessions, and assist people quickly when something needed to be changed.
We tracked badge printing by attendee, staff activity, sessions, and other event activity inside the Events App. Relevant data was synced back to netFORUM in real time as needed.
The goal was not to replace netFORUM. The goal was to create a faster and simpler operational layer on top of it.
07Piloting the app
Our first event of the year was a much smaller event, so it became the perfect pilot.
Being at the event and watching how people interacted with the system taught us a lot. The self-service badge printers were especially helpful because we could see the attendee experience in real time.
After the pilot, we made several improvements. For the next event, we bought additional printers so we could support two self-service kiosks and two staff-supported kiosks.
Because the system worked in real time, we were able to keep registration open throughout the event instead of closing it far in advance.
We also changed the exhibitor login process. We originally used link-based login, but we learned that not all vendors had access to their email on the phones they were using for lead tracking. So we switched to an OTP code approach, which worked better in practice.
We also improved staff tools so staff could update badge information and print on-demand badges more easily.
08What I learned
The biggest lesson from this project was that internal tools have to fit the real workflow.
It is easy to design a system that looks good in a meeting. It is much harder to build something that works on a busy event floor with staff, attendees, exhibitors, printers, badges, QR codes, and real-time issues happening all at once.
Performance matters most when people are waiting in line. Even small delays feel big during check-in.
Staff also need simple tools. They should not have to understand the underlying database or switch between multiple systems to solve a basic attendee issue.
The pilot was extremely valuable because we learned things by watching people use the system that we would not have discovered from requirements alone.
09Final thoughts
The Events App started as a way to improve badge printing and session tracking, but it became much more than that.
It helped reduce manual work, improved the event experience, made CE tracking faster, supported exhibitors, and gave staff a better way to manage live event operations.
For me, this project was a good example of practical technology in a nonprofit setting: understand the workflow, respect the existing systems, build the right layer on top, and keep improving based on how people actually use it.
That is the kind of work I enjoy most — building systems that make real operational work easier.