Why we built it

Most school software is a filing cabinet with a web page in front of it. Attendance is a list you fill in; a report card is a page you print; homework is a notice you type twice. Nothing that happens in one place causes anything to happen anywhere else, so the work of joining them up falls on the people who can least afford it: the class teacher, and the one person in the office who knows where everything is.

We started from the opposite end. In Onflows, marking attendance is an event: it can notify a parent, update a report and land in the audit trail without anyone remembering to make that happen. Marking a register is an event. Admitting a student is an event. The work that follows the work is the software's job.

What we believe

• The domain is the product. A Student, an Enrolment, an Academic Year and a Guardian mean one thing across the whole system, and we do not redefine them per screen.
• Isolation is enforced, never merely promised. Your school's records are separated by the database itself. It is a property of how the data is stored, not a filter in our code that a bug could skip.
• History is not editable. Nothing is hard-deleted. A wrong receipt is corrected by a reversal or a refund that stays on the record, which is what an audit needs to see.
• AI belongs inside the work. Drafting a circular or spotting the attendance that is slipping, where the work happens, not a chatbot bolted to the side of it.

Where we are

Early, and honestly so. Onflows is running with its first schools rather than hundreds, and the pages on this site describe what the software does today, not what it will do next year. What we ship next is on the roadmap, without dates we cannot keep.

Being early is the reason the free plan exists. A school under a hundred students can put its records into Onflows, keep them there for nothing, and hold us to every claim on this site before it ever pays us anything. If we do not earn the upgrade, we have not built the right thing yet.