School OS
The school already has the data. It just can’t bill on it.
A student information system extended with the two things Kenyan schools actually run on and almost never have in software: transport and fee collection.
Demo login demo / SchoolOS-Demo-2026
Sample data only — feel free to click anything.
- School information system
- Module design & engineering · Deployment
- PHP · MariaDB · nginx · M-Pesa Daraja
- openSIS Classic (GPL) + two modules I wrote
Two of the biggest jobs in a school happen outside the software.
Student information systems are good at the academic record — enrolment, timetables, grades, attendance. Schools here spend most of their administrative energy somewhere else entirely: moving children safely, and collecting money.
Both usually live in parallel systems. Transport is a printed route list and a phone tree. Fees are a cash book, an M-Pesa statement, and someone reconciling the two by hand. Neither is connected to the student record, so nobody can answer simple questions: which children are on this bus today, and which of them are behind on fees.
Rather than rebuild a student information system from scratch, I took a mature open-source one and added the two missing halves.
From a vehicle to a child, and back again.
The transport module models the fleet the way the school actually thinks about it, then ties it to the student record so the roster is a query rather than a printout.
The fleet: registration, capacity, and what is actually roadworthy today.
Drivers and attendants, with the licence details the school is liable for.
Named routes broken into ordered stops — the unit parents actually care about.
Students attached to a route and a stop. This is what makes a roster answerable.
Charges and payments per assignment, so transport income is not a separate book.
A “My Transport” page so parents stop phoning the office to ask.
Money in, allocated, receipted — without a spreadsheet.
The billing module takes fees from definition all the way to a receipt, and treats mobile money as a first-class payment method rather than something reconciled afterwards.
What the school charges for, per school and per year.
Generate invoices across a whole cohort rather than one student at a time.
Recorded once, then auto-allocated to the oldest open invoice — the rule bursars apply by hand.
Daraja STK push initiated from the system, then confirmed by status query.
Printable invoices and receipts generated from the same record, not retyped.
Who owes what, with SMS reminders instead of a phone list.
A dashboard showing what was actually collected, by period.
Modules that install themselves.
Both modules are self-installing: on first page load they create their own tables
(transport_* and billing_*, six each) and seed their permissions
into the host system’s profile table. There is no migration step and no SQL to run by hand
— which matters when the person deploying is a school IT contractor, not a developer.
Permissions are seeded per profile type rather than per profile ID, because the numeric IDs differ between installations. Hardcoding them is the kind of shortcut that works on your machine and silently locks out every real school.
Credentials for M-Pesa and SMS are stored per school in a settings table rather than in code, so one deployment can serve more than one school without a rebuild.
Built on openSIS Classic, which is open source under the GPL. The student information core is theirs; the transport and billing modules, the premium interface skin, and this deployment are mine.
See it yourself.
Rather than screenshots, the whole system is running with sample data and an open login. Both modules appear in the main navigation alongside the standard ones.
Signed in as the demo account. Transport and Fees & Billing sit in the main navigation beside the stock modules.
Demo login demo / SchoolOS-Demo-2026
What the system changes.
The roster and the ledger become properties of the student record. Which children are on which bus, and which of them are behind on fees, stop being two separate investigations and become one query.
The specific structural win is payment allocation: recording money once and letting the system apply it to the oldest open invoice removes the manual step where most fee-book errors are born.
School rollout metrics — to be published once in production use