University Society Events Manager with QR Check-In
University societies run events through WhatsApp groups, Google Forms and a paper sign-in sheet, so nobody knows how many people will turn up, who actually came, or which members are active. Build a web app where societies publish events, members RSVP against a capacity with a waitlist, and volunteers check people in at the door by scanning a QR code, even on weak venue Wi-Fi. A small, real system with roles, data integrity and a pilot you can run on your own campus.
Beginner
Achievable by one student in a semester with familiar tools.2 semesters · 2 to 3 students
7 to ship
4 optional extrasSuggested stack
What you should ship
- Role-based access for admin, society lead, volunteer and member, enforced on the server for every request
- Event creation with capacity, registration deadline and an automatic waitlist that promotes the next person on cancellation
- An automated test proving that two simultaneous RSVPs for the last seat cannot both succeed
- Signed QR tickets and a volunteer scanner page that rejects duplicate and forged tickets
- Offline check-in that syncs scans when the connection returns, without losing or duplicating any
- Attendance reports per event and per member, exportable as CSV
- A pilot with a real society covering at least two events, with check-in times and feedback in the report
If you have time left
- Participation certificates generated as PDFs for members who attended
- Calendar invites and reminder emails the day before an event
- Joint events hosted by two societies with shared capacity
- A public campus events page with search by date and society
Problem
Most university societies manage events with a mix of WhatsApp announcements, a Google Form for registration and a printed sheet at the door. The form has no capacity limit, so a 60-seat room gets 140 sign-ups. The paper sheet is never typed up, so the society cannot tell its patron or the student affairs office how many people attended, and members who help at every event get no record of it.
What you build
A web app for all the societies on one campus:
- Societies with roles: platform admin, society lead, volunteer and member.
- Events with a venue, capacity, registration deadline and optional approval.
- RSVPs with a waitlist that promotes the next person automatically when someone cancels.
- A personal QR ticket per RSVP, and a volunteer scanner page that checks people in.
- Attendance reports per event and per member, exportable as CSV.
Suggested architecture
- One web app is enough: a React front end, a Node.js and Express API, and MongoDB. Resist microservices.
- Enforce roles on the server for every request. Hiding a button is not authorisation.
- Model capacity carefully. Two people taking the last seat at the same moment must not both get it. Use an atomic update or a transaction, and write a test that proves it.
- The QR code should encode a signed token (for example an HMAC over the RSVP id and event id), not a plain id, so tickets cannot be guessed. Mark a ticket as used on the first scan and show the volunteer a clear "already checked in" result on the second.
- Make the scanner page work offline: download the ticket list for the event before doors open, record scans locally, and sync when the connection returns.
Milestones by month
- Month 1: interviews with two or three society leads, data model, roles, authentication, event creation.
- Month 2: RSVPs, capacity and waitlist, email notifications, the concurrency test for the last seat.
- Month 3: QR tickets, scanner page, duplicate scan handling, attendance reports.
- Month 4: offline scanning and sync, accessibility pass, deployment.
- Months 5 and 6: pilot with at least one real society over two or more events, fix what breaks.
- Months 7 and 8: second iteration from pilot feedback, testing, report and demo.
How it will be assessed
- A live demo taking one event from creation to attendance report, including a waitlist promotion and a duplicate scan.
- Automated tests for role checks and the concurrent last-seat case.
- Pilot evidence: number of RSVPs, check-in time per attendee compared with the paper sheet, and what the society leads said.
- A report that explains the data model and the decisions behind it.
Pitfalls
- Building a social network. Comments, feeds and chat are out of scope.
- Trusting the client for roles or capacity.
- Collecting more personal data than you need. A roll number and an email address are enough; do not store CNIC or phone numbers unless a society truly needs them.
- Leaving the pilot to the last month. Real users find problems that take weeks to fix.
Ideas and guidance, not finished projects
These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.
Not sure this one fits you?
I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
Follow along
New writing, resources and project ideas land here first.