Appearance
What this system is
A quick tour of what you have bought and what it can do. Time to read: 4 minutes.
In one paragraph
This is a school management system that runs many schools from one installation. You install it once on your own hosting. Each school gets its own login, its own data and its own settings, and none of them can see each other. Staff work in a web panel; parents, teachers and drivers get mobile apps that talk to the same server.
The four ways people use it
| Who uses it | What for | |
|---|---|---|
| Web panel | You, and each school's office staff | Everything — admissions, fees, exams, staff, reports |
| Parent app | Parents | Their child's attendance, marks, fees, homework, notices |
| Staff app | Teachers | Attendance, marks, homework, their own leave |
| Driver app | Bus drivers | Trip status and live location for the bus |
The three apps are yours to publish under your own name — see the mobile apps section.
What is included
The system is built from 29 modules. Six are always on; the rest can be switched on or off per school, so a small school is not buried in features it will never use.
Always on
- Student Information
- Academics
- Fees Collection
- Human Resource
- Offline Examinations
- Certificates & Documents
Switch on when needed
| Homework | Library Management | Transport |
| Hostel | Inventory | Asset Management |
| Accounts & Finance | Front Office | Communications |
| Study Center | Live Classes | Online Examinations |
| Lesson Planner | Assessment | CBC / Competency Academics |
| Digital Evaluation (OSM) | Parent–Teacher Meetings | Student Health Records |
| Biometric Attendance | QR Code Attendance | Knowledge Base & Chatbot |
| AI Assistant & Analytics | Apps Center |
Switching modules off is a kindness, not a limitation
A primary school with no buses and no hostel should have Transport and Hostel turned off. Their staff then never see those menus. You can turn anything back on later without losing data.
One database, or one for each school?
This is the first question most technical buyers ask, so here is the straight answer.
One database, shared by every school. Every record carries the school it belongs to, and schools only ever see their own.
The obvious-sounding alternative — give each school its own database — looks safer and turns into a trap as soon as you grow.
Why one database, honestly
| With 50 schools | One shared database | One database per school |
|---|---|---|
| Applying an update | Once | 50 times, and any failure leaves schools on different versions |
| Adding a school | Minutes, from your panel | Create a database, install, configure, connect |
| Nightly backups | One job | 50 jobs to run and monitor |
| Group-wide reporting | A normal query | Query 50 databases and stitch the results together |
| Shared hosting | Fine | Most plans cap how many databases you may create |
| A school that grows | Nothing to do | Nothing to do — but you now maintain 50 of everything |
The pattern that kills you is updates. Every release has to reach every school. With one database that is one operation. With fifty, it is fifty chances to fail, and you find out about the failures from your customers.
So how are schools kept apart?
Separation does not come from separate databases. It comes from the school being part of the data itself, and every screen being tied to the school of the person using it. A school's staff have no route to another school's records — there is no menu, no URL and no report that crosses the line.
On top of that you get tools that give you the good part of one-database-per-school without the cost:
| Tool | What it does |
|---|---|
| School Data Explorer | Look at exactly one school's data on its own, from your panel |
| Per-school backup | Back up a single school without touching the others |
| Per-school restore | Restore one school without rolling back everybody |
| Extract a school | Pull one school out of a full backup on its own |
That last one is the answer to "what if a school leaves?" — you hand them their own data, extracted cleanly, and remove them. That is the one genuine advantage of separate databases, and you have it anyway.
What makes it different from a single-school system
Most school software is sold one copy per school. Each school gets its own install, its own database, its own update. That model works until you have more than a handful of customers — then it becomes a full-time job.
| This system | One copy per school | |
|---|---|---|
| Servers to run | One | One per school, or one crowded one |
| Releasing an update | Once, everybody has it | Once per school, by hand |
| Adding a customer | Minutes, from your panel | A fresh install every time |
| A customer's setup drifting | Cannot happen | Normal, and painful to diagnose |
| Your role | Running a service | Running fifty installations |
| What you can charge | A monthly subscription | A one-off licence, then support |
The second column is a software business. The first is a subscription business — which is why the platform side has plans, billing, payment gateways and per-school switches built in. You add a school, it starts paying, and it is on the same version as everyone else from day one.
Alongside that:
Groups get their own level. A trust running several branches can have a head office login that sees across its own branches — and nothing else. See Who does what.
Schools only pay for what they use. 23 of the 29 modules can be switched on and off per school, so a plan can genuinely differ between customers.
What you need to run it
Ordinary shared hosting is enough for most schools, including groups running many schools together. The full answer, and the few features that need more, is in Which hosting do I need? — read that before buying anything.
Where to go next
- Which hosting do I need? — buy the right thing first
- Who does what — decide who gets which login
- Install — get it running
- Configure — email, SMS, payment gateways