School Election Management System
A centralised digital election platform that replaces spreadsheet-based school elections, with multi-school administration, audit logs and a login-free student voting interface.
Overview
The School Election Management System is a complete election platform built to replace manual, spreadsheet-based election workflows with one centralised system. It covers the full lifecycle: a school is set up, candidates are registered against positions and houses, an election is opened, students vote without needing an account, votes are recorded securely, and results are published.
It is a multi-school system with separated Super Admin and School Admin panels, running on a Flutter Web frontend against a Laravel API and a PostgreSQL database.
Problem
School elections were being run on spreadsheets. Ballots were tallied by hand, results were slow to produce, and there was no reliable record of who had voted or what happened afterwards.
Manual talling is also error-prone and unverifiable. When a result is disputed there is no audit trail to inspect.
Voting itself is sensitive: a student should be able to cast a vote without creating an account or learning to use an administrative system, and each voter must be able to vote only once.
Solution
A multi-school Laravel API where a Super Admin manages schools globally and each School Admin runs their own election inside their own data boundary.
A Flutter Web frontend: administrative panels for staff, and a deliberately simple, focused voting interface for students that requires no login.
Server-side vote recording with one-vote-per-voter enforcement, voter receipts and audit logs so any result can be traced after the fact.
A PostgreSQL database and a migration path away from a local MySQL/XAMPP development environment toward hosted PostgreSQL on Supabase.
Features
Each feature is labelled by its current state: Implemented means it is built and working, Integrated means it is connected to hardware or an external service, and In Development means it is actively being built and is not yet complete.
Super Admin panel
ImplementedGlobal management of schools and the overall platform.
School Admin panel
ImplementedPer-school administration with access scoped to that school only.
Student and voter management
ImplementedVoter records per school, which later govern voting eligibility.
Candidate management
ImplementedCandidates registered against positions and houses before an election opens.
Election management and positions
ImplementedElections created with their positions, then opened and closed by the school admin.
Houses
ImplementedHouse groupings used to organise candidates and results.
Voting system
ImplementedA no-login student voting interface, with the vote itself recorded and validated server-side.
Results and voting status
ImplementedResults published per position, with live voting status for administrators.
Audit logs and voter receipts
ImplementedTraceable activity records and a receipt for each recorded vote.
Multi-school architecture
ImplementedOne platform serving many schools with separated data and access.
Flutter Web frontend
ImplementedWeb client for both the admin panels and the student voting flow.
Laravel API and PostgreSQL
ImplementedBackend API and relational data model backing every flow.
Hosted PostgreSQL migration
In DevelopmentMoving from a local MySQL/XAMPP setup to PostgreSQL on Supabase for a hosted deployment.
Technology
Frontend
- Flutter Web
- Dart
- Responsive admin UI
Backend
- Laravel
- PHP
- REST API
- Authentication
- Role-based access
Data
- PostgreSQL
- Relational data modelling
- Migrations
Operations
- Git
- GitHub
- Environment configuration
Architecture
A three-tier system: Flutter Web clients, a Laravel API enforcing multi-school boundaries and vote integrity, and PostgreSQL holding election, candidate and vote records.
Layers
Flutter Web
Admin panels plus a login-free student voting interface
Laravel API
Auth, multi-school scoping, vote validation, audit logging
PostgreSQL
Schools, voters, candidates, positions, houses, elections, votes
Workflow
- School Setup
- Candidates
- Election
- Student Voting
- Secure Vote Recording
- Results
Integrations
- Supabase hosted PostgreSQL (migration in progress)
Challenges
Voting without accounts
Students must vote without the friction of registration, but the system still has to know who voted and stop a second vote. That pushed the identity check and the one-vote rule to live on the server rather than in the client.
Multi-tenant data boundaries
Many schools share one database, so every query needs a school scope. Getting this right per query, rather than per screen, is what keeps one school's data invisible to another.
Trustworthy results
Because the previous process was hand-tallied spreadsheets, results had to be defensible. Audit logs and receipts exist so a disputed result can be explained rather than argued.
Moving from local MySQL to hosted PostgreSQL
Development ran on a local MySQL/XAMPP environment. Moving to hosted PostgreSQL meant aligning the schema with PostgreSQL specifics and preparing the database for a deployment that is configured entirely through environment variables.
My Contribution
- Designed the multi-school architecture, including how admin roles and data boundaries are separated.
- Built the Laravel API: authentication, role-based access control, school scoping, and all election, candidate, position and house endpoints.
- Developed the Flutter Web frontend, including both admin panels and the student voting interface.
- Implemented secure vote recording, one-vote-per-voter enforcement, voter receipts and audit logs.
- Designed the PostgreSQL schema and wrote the migrations.
- Handled the migration path from a local MySQL/XAMPP environment to hosted PostgreSQL on Supabase.
Results / Current Status
Spreadsheet-based election handling is replaced by one centralised system covering setup through results.
Every recorded vote has a receipt and an audit trail, so results can be traced after an election closes.
Students vote through a focused interface with no login, while identity and one-vote enforcement remain server-side.
The platform currently runs against a local MySQL/XAMPP environment; the move to hosted PostgreSQL on Supabase is the remaining step before public deployment.