CASE STUDY · SAAS · EDUCATION
Bringing school fee collection, payment follow-ups and parent communication into one product.
SchoolPay is a school fee management platform that connects the work schools do every month: keeping student records, creating fees, following up on outstanding balances, recording payments and giving parents a clear view of what they owe. I built the application around those connected workflows, not a collection of isolated dashboards.
THE CHALLENGE
Make the product better without adding unnecessary complexity.
Monthly fee collection is not just sending a bill. Schools need accurate student and class records, fees that can vary by student, a way to track partial payments and a reliable process for following up with parents when balances remain outstanding.
The product also needed different experiences for school staff, parents and the people running the platform. Each group should see the information and actions relevant to them without sharing one oversized interface or exposing another school's records.
WHAT I BUILT
The work behind the result.
School billing and student records
Built school and class management, student records, monthly fee generation and individual or class-level fee adjustments, with invoice status tied to the payment record.
Payments and parent portal
Created a parent-facing view of fees and payment history, including payment proof submission, alongside a school workflow for reviewing proofs and recording approved payments.
Reminders and reporting
Added overdue-fee reminders through WhatsApp, with configurable templates and credit tracking, plus monthly school dashboards and collection reports.
Platform operations
Built separate administrative and agent areas for school onboarding, packages, subscription billing and related operational workflows.
TECHNICAL APPROACH
Keep the architecture focused on the workflow.
- 01
Model students, classes, charges, invoices, payments and proofs as connected records so a balance can be traced back to the underlying fee and payment activity.
- 02
Keep parent, school and platform workflows distinct, with authenticated access and school-scoped data for the application's private records.
- 03
Separate payment proof submission from school approval: a submitted receipt is not treated as a completed payment until the school reviews it.
- 04
Use Next.js for the application and PostgreSQL for structured financial and school records, with reusable dashboard, table and form components across the product.
Next.jsReactTypeScriptPostgreSQLDrizzle ORMWhatsApp Cloud API
OUTCOME
What changed after the build.
One monthly collection workflow
Schools can move from student records and fee creation to payment tracking and monthly reporting within the same application.
A clearer path for parents
Parents can see their children's balances and payment history and submit payment proof without needing access to the school's administrative area.
Operations beyond the school dashboard
Dedicated platform and agent areas support onboarding, subscriptions and package administration alongside each school's day-to-day fee management.
KEEP EXPLORING
Related work and thinking.
START A PROJECT
Have a recurring business workflow that needs more than spreadsheets and reminders?
Share how the process works today, who needs access and what happens when something needs follow-up. I can help turn those steps into a focused product with a clear path from first input to final outcome.
Tell me what you are building