VoteSafe
Secret ballots for universities, schools and organisations.
- Role
- Product Engineer
- Period
- Jun 2026 to present
- Status
- In development
A voting platform for institutions: layered voter verification, secret ballots by default, duplicate-vote protection, receipts, live monitoring and an audit trail, with integrity anchoring that never puts a ballot or personal data on-chain.
Screens show the VoteSafe frontend running on its own mock data.

Overview
Student unions, schools and member organisations run elections that matter to the people in them, usually on tools that were never designed for voting. VoteSafe is built specifically for that: an operations console to run an election, a voter app to take part in one, and a public transparency page to trust the result.
The problem
Institutional elections need four things that pull against each other: secrecy (no one can see how you voted), eligibility (only the right people vote, and only once), verifiability (anyone can trust the count) and simplicity (a first-year student can do it on their phone in a minute).
The solution
Three surfaces
- Operations console: create an election, build the ballot and registration form, manage the voter roll and verification, launch, monitor live, publish results and review the audit log.
- Voter app: register, verify, vote and keep a receipt.
- Public pages: elections, transparency and help, readable by anyone.

Principles, decided up front
- Secret ballots by default.
- Layered verification before a voter is admitted.
- Duplicate-vote protection and a full audit log.
- Integrity anchoring that proves the record hasn't changed without storing ballots, biometric templates or personal data on a blockchain.

Architecture
Surfaces
- Operations console
- Voter app
- Public & transparency pages
Election lifecycle
- Create
- Ballot & form builder
- Registration
- Verification
- Launch
- Monitoring
- Results
- Audit
Backend (planned)
- NestJS API
- Receipts
- Audit log
- Integrity anchoring
Progress

The frontend is built across all three surfaces (34 routes covering the full election lifecycle, from creation to audit), built from page-by-page handoff documents written before any code. The NestJS backend follows its own A-to-Z plan next.
Lessons learned
- Write the principles before the screens. Secrecy and verifiability decide the data model; the UI follows.
- Plan in handoff documents. A page-by-page frontend plan and an A-to-Z backend plan let the two halves be built independently.
Technology stack
- Next.js
- TypeScript
- Tailwind CSS
- NestJS
