CampusBallot

What did you make?
I built lCampusBallot, a desktop app (C++/Qt6) for running secure campus elections, student council elections, class rep elections, club leadership elections, etc. It handles the whole process: registering students and candidates, running the vote through a dedicated kiosk interface, and generating live results. It supports role-based logins (Super Admin, Election Admin, Teacher, Student Volunteer, Observer, Result Auditor), encrypts and digitally signs each vote, keeps a tamper-evident audit log of every action, and can back itself up automatically. Data is stored locally in SQLite by default, with an optional Firebase sync mode for multi-machine setups.

What was challenging?

Getting the security pieces to actually work together, encryption, hashing, and digital signatures on votes, plus tamper detection on the stored records, without slowing down the voting flow or making it fragile.
Designing the role-based access control so that six different roles each see and can do only what they should, without the permission logic turning into spaghetti.
Handling student identity verification (matching against uploaded files/rosters, plus QR/barcode/RFID support) so the same student can’t vote twice while still keeping the kiosk experience fast and simple for voters.
Making the Firebase-backed multi-machine sync path reliable was noticeably harder than making the local SQLite path reliable, which is still the least battle-tested part of the app.

What are you proud of?

The audit log — every login, vote, and admin action is timestamped, hashed, and effectively tamper-evident, so there’s a real accountability trail if anyone questions a result.
The full flow works end-to-end: setup wizard → student/candidate registration → live voting on the kiosk → real-time results dashboard, all in one cohesive app rather than a collection of scripts.
The plugin architecture — I designed it to be extensible (for custom storage backends and extra functionality) rather than hard-coding everything.

What should people know to test your project?

It’s a pre-release build — run it once through a full rehearsal (test election, test students, test candidates) before trusting it with a real vote.
On first launch, it opens a Setup Wizard: choose local SQLite storage (the most tested path) or Firebase (experimental), then create the admin account.
Log in as admin to add students, create an election, add and approve candidates, then start voting and open the Voting Kiosk view actually to cast votes.
Windows may show a SmartScreen warning since the build isn’t code-signed yet — that’s expected, not a red flag.
Check ballot.log in the app’s data folder if anything crashes or behaves oddly.