One simple platform that runs a whole school
How Brightcodex designed, built and launched a multi-school SaaS for Pakistani schools — fees, attendance, timetable, payroll, exams and a parent app in one product.
At a glance
- Product
- School Management System — multi-school SaaS
- Built by
- Brightcodex (our own product)
- For
- Private schools in Pakistan (Karachi first): owners, principals, coordinators, accountants, teachers, parents
- What we delivered
- Product design, web app, parent PWA, API, database, deployment, CI/CD, marketing site
The problem
Most small and mid-sized schools run on paper registers, Excel sheets and calculators. Fees are in one book, attendance in another, the timetable hangs on a wall and salaries are worked out by hand. Every job is done twice and nothing agrees with anything else.
Software that exists is often built for other countries, needs fast internet all day, and is too complicated for the people who actually use it — a clerk at the fee counter, a teacher with a phone, a parent who barely uses apps. Schools also want to print on cheap black-and-white printers, pay by EasyPaisa, JazzCash or bank transfer, and reach parents on WhatsApp.
The goal
Build one product that passes a hard test we set ourselves: "so easy that a 10-year-old could use it" — while staying solid enough to serve thousands of schools, each with completely private data.
What we built
A single system with one record of every student, teacher and parent, used by every screen.
Fees & vouchers
Set fees per class once; every month review the bills and print a whole class as one PDF with three copies per A4 page (student, bank, school). Designs are black-and-white friendly (no ink wasted) and include the school's logo. Optional late fee, discounts, earlier balances, receipts and WhatsApp links. Students who leave keep their dues on a fee account, so money is never lost.
Automatic timetable
The school day, rooms, lectures per subject and teacher availability go in; a clash-free timetable comes out (or place lessons by hand and get warned before a mistake). When a teacher is off, the system lists free teachers and arranges covers. Timetables print on A4 for the school, each class and each teacher.
Attendance that works offline
Teachers mark class sheets on a phone; if the connection drops, records are saved on the device and sync later. Staff check in on a gate tablet with a PIN (also offline), by QR code, or from a fingerprint machine's file.
Salaries
Attendance, leave and extra lectures feed a monthly payroll run. Every rule (late marks, leave limits, day divisor, cover pay) is a setting the school chooses. The owner approves; each employee sees their own payslip.
Exams & results
Subject teachers enter marks; the school's own pass marks and grade bands decide results and positions; report cards, result sheets and admit cards print on A4; results are published to parents when the school decides.
Notices
Announcements to a class, the whole school or staff, sent as email from the system with a ready WhatsApp link per parent.
School report
One page for the owner, principal and coordinator: attendance by class, fees collected and owed, exam results, staff attendance, salaries and timetable for any dates.
Parent app (PWA)
Installs from the browser on any Android or iPhone, no app store. Parents see fees due, attendance, published results and notices for each child — and only their own children.
Roles & permissions
Owner, principal, coordinator, accountant, teacher, parent: each person sees only what their job needs.
How we approached it
- 1
Design for the least technical user first
Plain English, big touch targets (48px minimum), pre-filled answers, and a step-by-step setup guide. Every screen was clicked through at phone width.
- 2
Print like a Pakistani school prints
Landscape A4 with three voucher copies, hatching and outlines instead of solid ink, unique voucher numbers and barcodes.
- 3
Assume weak internet
Offline queues in the browser with idempotent sync, an offline gate tablet with locally verified PINs, and an installable app shell.
- 4
Let the school decide
Late fees, pass marks, grade bands, attendance timings, leave limits and salary rules are settings, not code.
- 5
Ship in phases, document each one
Each phase (fees → timetable → attendance → payroll → exams → communication → parent app) was built, tested, documented and released before the next began.
Under the hood (for technical readers)
- Multi-tenancy without row-level security: MySQL has no RLS, so tenant safety is enforced in four layers — scoped query helpers that add the school to every query, a lint rule that bans raw tenant queries, an SQL guard that rejects queries on tenant tables that don't filter by school, and composite foreign keys so a record can never point at another school's record. A generated isolation test calls every route that takes an ID with another school's IDs and checks that nothing is readable or changed.
- Money is exact: amounts are whole paisa integers and all fee movements go through an append-only ledger (database triggers block updates and deletes); balances are sums, never stored numbers.
- Pure, testable business rules: the timetable generator, payroll calculation and exam results are pure functions with unit tests; results are never stored, always computed from marks and the school's rules.
- Offline-first pieces: a service worker and IndexedDB queue for attendance and the gate tablet; mutation IDs make replays safe.
- Email: SMTP through AdonisJS Mail with Edge templates and a database-backed queue with retries.
- PDFs: vouchers, report cards, result sheets, admit cards, payslips and timetables are generated on the server (PDFKit) for identical output on any device.
- Deployment: frontend on Vercel; API on a CentOS VPS behind Cloudflare (nginx → systemd service). GitLab CI runs lint, type-check and the full test suite on every push, then deploys the release automatically with a health check and automatic rollback if the new version doesn't start.
- Quality bar: 96 database migrations, roughly 250 automated tests (including the tenant-isolation sweep), strict TypeScript and lint on every commit.
Results
- A complete school-operations product, live at sms.brightcodex.com, with a public landing page, self-service registration and a 30-day free trial (no card; schools can pay by EasyPaisa, JazzCash or bank transfer)
- Roughly 80 screens, 300+ API endpoints, ~36,000 lines of API code, ~25,000 lines of front-end code and ~9,000 lines of tests
- One student record feeds fees, attendance, exams and the parent app — no double entry
What we learned
- Simplicity is a feature you have to defend: every extra box on a screen costs a first-time user.
- "Works offline" is mostly about deciding what may safely be queued (attendance, check-ins) and what must not (money).
- Making rules configurable early (late fees, salary rules, pass marks) avoided a custom build for every school.
What's next
AI insights that tell the principal what needs attention, automatic WhatsApp messages, board (BSEK) tools, and online fee payments.
See it live
Start a free 30-day trial — no card needed — or talk to us if you have a product of your own in mind.