A school management system Belize schools can actually run

I built Scholar, a school management system Belize schools can run without hiring a technician, for a selfish reason. My child's school ran on spreadsheets. Not one spreadsheet, five, each kept by a different person, each slightly different, and the "backup" was an external USB hard drive that somebody copied the files onto when they remembered. I watched a school full of capable, caring people spend their evenings retyping things and still not be able to tell me, on a Tuesday, whether my child had been marked present that morning.

That is the gap Scholar fills. It was built so that a parent can see what is happening with their child close to the moment it happens, so that teachers and parents talk to each other through something better than a class WhatsApp group, and so that the school's fee reminders go out on their own instead of depending on whoever has time to make calls.

What do Belizean schools actually run on today?

In my experience the honest answer is a mix of four things.

A paper attendance register that lives in a binder. A set of Excel or Google Sheets files, one per teacher or per office, each with its own idea of how a child's name is spelled. A WhatsApp group per class, where parents are told about early dismissal and where teachers receive photographs of sick notes. And the principal's memory, which is the most reliable system of the four and also the one most at risk.

Then there is the backup. At my child's school it was a USB drive in a drawer. It was copied when someone thought of it, which in a busy term means rarely. One failed laptop, one spilled drink, and a term of attendance and grades would have been gone. Most schools I have spoken to since are in the same position and know it, and feel vaguely guilty about it. They should not. It is what works when the alternative is an expensive product designed for a 2,000-pupil school in another country.

The real problem is that none of it scales, none of it survives staff turnover, and none of it can answer a simple question like "how many days has this child missed this term" without somebody counting by hand.

What should a school management system in Belize actually do?

I kept the feature list deliberately close to the ground, and I built the parent side first, because that was the side I was standing on.

• Student records. One place where a child's details, class, guardians and history live, rather than one row in each of five files.
• Classes and who teaches whom. A teacher logging in sees their class, not the whole school.
• Staff and teacher roles. Different people see different things. A teacher marks their own register, an administrator sees everything.
• Parent logins. Parents see their own children only, and nobody else's.
• Attendance. Marked by the teacher and visible straight away to administration and to the parent.
• Grades and report cards. Entered once, assembled into reports, not retyped at the end of term.
• Announcements and messages. The school posts once and every parent sees it; a teacher and a parent can message each other inside the system, with a record both can look back on.
• Billing. Monthly fees, payments and family balances in one statement, with reminders that send themselves.
• Pickup authorisation. A record of who is allowed to collect a child, which is a safeguarding matter and a frequent source of WhatsApp confusion.

There is more detail on the system itself on the Scholar project page, including how the parent-facing side is structured.

What a parent sees

This is the part I cared about most. When I log in as a parent I see my children and nothing else: today's attendance, recent grades, the school's announcements, any message from the class teacher, and our family's fee statement. If my child was marked absent at eight in the morning, I know before lunch, not at the parent-teacher meeting in November.

That changes the relationship between a teacher and a parent more than any feature list suggests. The conversation stops being "why didn't anyone tell me" and becomes "I saw the note, what can we do". Teachers get fewer calls about things the parent could have looked up, and the calls they do get are the ones that matter.

Fee reminders that do not depend on anyone remembering

Chasing fees is the job nobody at a school wants, and it is the one that quietly decides whether the school can pay its staff on time. Scholar keeps a running balance per family. When a family owes, the system sends a WhatsApp reminder on its own, on a schedule the school sets. The office can send one by hand for a particular family, pause automatic reminders for a family that has made an arrangement, and see at a glance who owes most. Payments are recorded against the statement, so the reminder stops the moment the balance is settled.

Nobody has to make the awkward call. The school still can, when a conversation is needed, but it is no longer the only way money gets collected.

Why module toggles matter more than features

Scholar is multi-tenant, meaning several schools can run on the same installation while each one's data stays completely separate. That matters because a primary school in a village and a secondary school in a town need different things, and neither should pay for the other's complexity.

Each school's modules, such as billing, attendance, report cards, announcements, messages and calendar, are switched on or off by a platform administrator. A school that does not want to publish grades through the parent portal simply does not have that section. A school that wants attendance and nothing else gets attendance and nothing else, and can turn the rest on next year.

This is the single design decision that has saved the most arguments. Schools do not reject software because it lacks features. They reject it because it demands work they did not ask for.

How do you move real student records off spreadsheets?

Carefully, and it takes longer than anyone expects.

The first school live on Scholar came to me with those five spreadsheets. They overlapped. Names were spelled three ways. Some children appeared twice because they had changed class. Guardian phone numbers were in one file and guardian names in another, and the two did not always agree.

The migration work was not technical, it was reconciliation. I wrote scripts to pull the files together, produced lists of conflicts, and sat with the school while they decided which version of each record was correct. Then the reconciled data went in, and parent logins were generated from it, each parent linked to the right children and nobody else's.

The backup problem disappeared at the same time, without anybody having to remember anything. The data lives on a server that is backed up automatically every night, off the machine, and I can prove it by restoring a copy. The USB drive went back in the drawer.

That is the shape of every data migration I have done: a few days of mechanical work, and most of a week of somebody at the organisation making judgement calls that only they can make. If a vendor tells you migration is instant, they have not seen your files. I have written more about why this stage decides the success of a project in my notes on digitisation in the public sector.

Build, buy, or carry on by hand?

Here is the comparison I give schools that ask. There is no universally right answer.

Carry on by hand. Costs nothing up front. Works while the school is small and the staff are stable. Breaks the day a long-serving teacher leaves, the day the USB drive fails, or the day you need a figure for the Ministry by Friday.

Buy a hosted product from abroad. Fast to start. Usually priced per student per month in US dollars. Assumes a bank integration and a parent body that checks email. Your data sits on somebody else's server under somebody else's terms, and you cannot change the parts that do not fit.

Use something built for Belizean schools. Scholar is hosted, so there is nothing to install, but it was built here, around terms, report cards, fee cycles and WhatsApp rather than email. Each school gets its own separate tenant, its own modules, and its data back whenever it asks.

My honest view: if a foreign hosted product fits your school, buy it. If you find yourself planning to change how the school works so the software will accept it, stop and look at the third option.

How do I know the system works before parents see it?

This is the question I would ask if I were the principal, because a school management system fails in public. A parent logs in and sees the wrong child. A teacher marks a register and it does not save.

Before every release, an automated end-to-end test harness, meaning a programme that uses the system the way a person would, runs through the admin, teacher and parent roles against a sandboxed tenant, which is a throwaway copy of a school with fake data. It logs in, marks attendance, enters grades, checks what a parent can and cannot see, and reports any step that behaves differently from last time.

It is not glamorous work. It is the reason I can change something on a Tuesday and not spend Wednesday on the phone. It is also the reason I am comfortable with my own child's records being in it.

In-app help that is actually current

Every page in Scholar has help attached to it, and that help is updated whenever the page changes. Not a PDF manual from the year of installation. The reason is practical: schools train new staff in September with whoever is available, and the system has to explain itself.

Where to start

If you manage a school and this is on your mind, four steps before you talk to anybody about software.

1. Write down the five things that go wrong every term. Not features. Problems. Late report cards, attendance figures nobody trusts, fees chased by phone, parents who did not hear about early dismissal.
2. Collect every file that holds student data. All of them, including the one on the deputy's laptop and the one on the USB drive. Count them. That number tells you most of what a migration will involve.
3. Decide who owns the data. One named person at the school who can settle a conflict between two spellings of a child's name.
4. Pick one module to start with. Attendance is usually the right one. It is daily, it is visible to parents, and it proves the system to staff within a fortnight. Billing is usually the second, because it pays for itself.

When you have those four, you will have a far better conversation with any developer, including me. If you would like to talk through what this would look like for your school, you can reach me through the contact page.