Schools rarely fail at buying software. They fail at the rollover, when last term's data will not carry into this one. These are the questions to ask before you commit a session to any system.
Most school software demos look the same. Enrolment, attendance, results, fees, a parent portal. The differences only appear in week six, when a teacher cannot take a register on her phone, or at the end of term, when the report cards will not print correctly. Here is what separates a system a school keeps from one it abandons. ## Does it understand terms and sessions, or did someone hard-code three terms? Schools differ. Some run three terms, some two semesters, some have a mid-term break that affects attendance counts. If the structure is fixed in the code, every year you will fight it. Ask directly: can I define my own sessions and terms, and what happens to last year's data when I roll over? If the answer is vague, you will be re-entering pupils next September. ## Can a teacher take the register on the phone she owns? Not the phone in the demo. The one in her pocket, on the school's patchy wifi, in a classroom where she has four minutes between periods. A register should be one screen, one pass, one save. If marking thirty pupils makes thirty separate requests, it will fail halfway through on a weak connection and she will keep a paper list instead. Once teachers keep paper, the system is already dead. ## Are grading rules settings, or are they code? Continuous assessment weighting, exam weighting, grade bands, pass marks, position in class. Every school does these differently, and most schools change them at some point. These must be settings an administrator can change. If a developer has to be called to change a pass mark from 40 to 45, you have bought a liability. ## Will the report card print properly on A4? This sounds trivial and it is the single most common failure. Schools print. Parents expect a document. If the report card is designed only for a screen, somebody will spend the last week of term fighting with page breaks. Ask to print one during the demo, on the paper you actually use. ## Does the fees side show you who still owes? Billing is the easy half. The hard half is answering, in one screen: what did we bill, what has been collected, who is outstanding, and which invoices are part-paid. That is what the bursary needs on a Monday morning. If payments are collected online, the gateways matter. In Nigeria, that usually means Paystack, Flutterwave and Remita, plus bank transfer with a reference the bursar can reconcile. ## Can a pupil or parent see their own record, and nothing else? A portal is useful only if the isolation is real. A pupil should see their own attendance, results and invoices. A teacher should see their classes. An administrator should see their school, and if you are a group, one school's staff must never see another school's pupils. Ask how that isolation is enforced. The answer you want involves the database refusing it, not the application remembering to filter. ## Is there a record of who changed what? Marks get amended. Payments get recorded. Pupils get moved between arms. All legitimate, all worth logging with a name and a timestamp, because the alternative is a conversation that starts with "nobody touched it". ## The rollover question Finish every evaluation with this: show me a school moving from one session to the next. Pupils promoted, arms re-assigned, outstanding fees carried over, last year's results still readable. Any system can enrol a pupil in September. The one worth paying for is the one that still works the following September.