Sanket
A school-focused digital platform that pulls timetable, bell, attendance, ID cards, exam seating and elections into one multi-module application.
Overview
Sanket is a school-focused digital platform designed to bring multiple operational systems into one application. Instead of a school running separate spreadsheets, registers and printed schedules for each activity, Sanket models the school as a set of connected modules over a single backend.
It is one of my major ongoing software projects, and the one that most clearly shows how I work: the Flutter client, the Laravel API and the PostgreSQL data model are designed as one system, with hardware integrations treated as a first-class requirement rather than an afterthought.
Problem
School operations are fragmented. Attendance, timetables, bell scheduling, exam seating, ID cards and elections are each maintained separately, often in spreadsheets that different staff members edit independently.
The same student, teacher or class record has to be re-entered in each of those places, so data drifts and reports are assembled by hand at the end of each term.
Some processes cannot live in a spreadsheet at all — fingerprint attendance hardware, generated ID cards and automatic bell signalling need real software and real device integration.
Solution
A single Flutter application that staff and students use, backed by one Laravel API and one PostgreSQL database, organised into independent modules that share a common identity and data model.
Shared records mean a student or teacher is defined once and reused by attendance, seating, cards, elections and reports.
External systems plug in at the backend: fingerprint devices report in through dedicated endpoints, and content, timetables and bell timings are managed centrally so the app does not need an update to change a schedule.
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.
Digital school management
ImplementedCentral records for classes, sections, subjects and students feeding every other module.
Digital bell and timetable system
ImplementedBackend-managed periods and bell timings that drive the app, so schedule changes do not require a release.
Teacher attendance
ImplementedTeacher check-in and records with reporting built on the same attendance model.
Fingerprint attendance hardware integration
IntegratedDevice-side fingerprint attendance reports into the backend, which records and reconciles the events.
Student ID card generation
ImplementedPrint-ready student identity cards generated from live student records.
Teacher ID card generation
ImplementedStaff cards generated from the same identity system used across the platform.
Exam seat planning
In DevelopmentExam hall and seat allocation driven by class size and available rooms, still being completed.
School election integration
IntegratedReuses the School Election Management System as a module, so election data shares the school's identity records.
Student and teacher data management
ImplementedCreate, update and archive records once, reused by attendance, cards and reports.
Backend-managed content and timings
ImplementedContent, announcements and timings are served by the API rather than hardcoded in the client.
Reports and exports
In DevelopmentAttendance and record exports are being finished on top of the existing data layer.
Multi-module architecture
ImplementedEach module is developed and shipped independently over shared infrastructure.
Technology
Application
- Flutter
- Dart
- Flutter Web
Backend
- Laravel
- PHP
- REST API
Data
- PostgreSQL
- Database design
- Migrations
Integration
- Fingerprint attendance hardware
- Receipt / ID card printing
Architecture
Requirements from the school are captured in a Flutter client, expressed through a Laravel API, persisted in PostgreSQL, and extended by hardware and external integrations at the edges.
Layers
School Requirements
Operational needs defined by school staff
Flutter Application
One client across mobile, web and desktop
Laravel / API Backend
Modules, roles, validation and business rules
PostgreSQL Database
Shared relational model for every module
Hardware / External
Fingerprint devices, ID card printing, services
Integrations
- Fingerprint attendance devices
- ID card generation and printing
- Shared election module
Challenges
One identity across many modules
Attendance, cards, seating and elections all need the same student and teacher records to stay consistent. Solving that once in the data model was cheaper than reconciling duplicates later.
Hardware that does not speak HTTP cleanly
Fingerprint devices push events in bursts and occasionally out of order. The backend has to accept idempotent writes so a retried event does not double-count an attendance record.
Schedules that change without an app release
Timetable and bell timings are operational data, not code. Moving them into the API keeps the client stable while the school adjusts its day.
My Contribution
- Designed and built the multi-module architecture, including how modules share identity and data.
- Developed the Flutter application and its API integration layer.
- Built the Laravel backend, its authentication and role-based access control, and the PostgreSQL schema and migrations.
- Implemented the attendance flow and the fingerprint hardware integration, including event handling on the server.
- Implemented student and teacher ID card generation.
- Built backend-managed content and bell/timetable configuration.
- Currently developing exam seat planning and the reports and exports layer.
Results / Current Status
Sanket is an active, ongoing project rather than a finished product, and each module is delivered independently over a shared foundation.
Fingerprint attendance and ID card generation run as working integrations rather than manual substitutes.
Timings and content are now data-driven, so routine school changes no longer need a new build.
Exam seat planning and reporting are the remaining work before the module set is complete.