What a Nigerian School Portal Must Do: Results, Fees, Parents and Staff

Many schools start with a website and later realise they need something bigger. The website tells parents who you are. A portal does the daily work: it holds results, fees, attendance and messages, and it lets the right people see the right things.

This article is a checklist. Use it to write a brief for a developer, or to judge a portal someone is selling you. We do not claim here that XpiriaTech has a ready-made school portal product. This is something we build as a custom project, and we say so plainly, so you know what you are asking for.

If you only need a school website with online registration and payments, read How to Build a School Website With Online Registration and Payments first.

Start with roles: who can see what

Everything else depends on this. Write down the people who use the system and what each may do:

Role	Typically can
Proprietor / owner	See reports across the school, fees paid, staff activity
Principal / head	See all classes, approve results, send notices
Teacher	Enter scores for their own subjects and classes only
Class teacher	Add comments and attendance for their class
Bursar / accounts	See fees, record payments, issue receipts
Parent	See only their own children's results, fees and notices
Student	See their own results and timetable, if you allow it
Admin	Create users, set up terms and classes

The most important rule: a parent must never see another child's data. Test this on purpose before launch.

Result processing

This is usually the first thing a school wants, and the most sensitive. A good result module:

• Lets teachers enter continuous assessment and exam scores, with the school's own weights (for example tests, assignments and exams adding to 100).
• Uses the school's own grading scale, not a fixed one. Primary, secondary and nursery sections often differ.
• Works out totals, averages, grades and class positions automatically.
• Handles subjects that some students do not take.
• Lets the head review and approve results before parents can see them.
• Produces a report card as a printable PDF, with the school's logo, comments and signature.
• Keeps results by term and session, so you can see a child's progress over years.
• Records who changed a score and when. This protects teachers and the school when a parent disputes a grade.

Ask any developer: "What happens when a teacher corrects a score after the head approved the results?" The answer tells you a lot.

Fee collection

Money is where schools lose the most time. A good fee module:

• Sets fees per class and per term, with extra items like uniform or transport.
• Lets parents pay online (card or transfer), and marks the invoice paid automatically when the payment arrives.
• Gives each student a clear balance: what was billed, what was paid, what is owing.
• Issues a receipt to the parent.
• Supports part payment and shows what is left.
• Lets the bursar record cash or bank deposits that arrived outside the system.
• Can block result access for unpaid fees if the school wants that rule, as an option the school controls and not a hidden setting.
• Gives the owner a daily and termly report.

For online payment, make sure the developer handles payment confirmations properly: signed messages, one credit per payment, and a way to catch late ones. We explain the traps in five payment integration mistakes.

Attendance, timetable and notices

Smaller features that parents notice every day:

• Attendance taken by the class teacher, with a summary for parents.
• Timetables for each class and each teacher.
• Notices and circulars sent to all parents, one class or one parent, by email, SMS or the portal.
• A calendar of term dates, holidays and events.
• A way to contact the school that goes to the right person.

What "multi-tenant" means

You will hear this word if one organisation runs several schools. Multi-tenant means one installation of the software serves many schools, but each school sees only its own data, with its own logo, classes, fees and users.

It is cheaper to maintain than ten separate copies, and an improvement helps every school at once. But it needs careful design, because a mistake could show one school's data to another. If you run a group of schools, ask how the system keeps them apart and how the group owner sees the combined picture.

Data protection is not optional

A school holds names, addresses, photos, results, health notes and payment history of children. In Nigeria, the Nigeria Data Protection Act 2023 applies to this kind of data. We are not lawyers and this is not legal advice, so speak to one. But your portal should at least:

• Collect only what the school needs.
• Protect logins with strong passwords, and offer a way to reset them safely.
• Record who looked at or changed sensitive data.
• Let you remove a leaver's access quickly.
• Back up the data daily, and test that a backup can be restored.
• Be hosted somewhere you can name, with a contract that says who owns the data. The school owns it.

Things a good developer will ask you

If the developer asks no questions, be careful. A good one will ask:

• How many students, classes and subjects do you have?
• Do you run nursery, primary and secondary sections with different scales?
• Who approves results, and what is the order of approval?
• How do you handle fees today, and what exceptions exist?
• What do parents ask for most often?
• Who will manage the system after launch?

Build or buy?

A ready-made school product can be cheaper and faster, if it fits how your school works. A custom portal fits you exactly but costs more and takes longer. Many schools start with the result and fee modules only, and add the rest later.

Talk to us

If you want a portal built around your school's real rules, we can build it as a custom project. Describe what you need and we will tell you honestly what to build first. Start with our full-stack development service, or use the quote builder to list your features.