Skooldrive

What it does

Skooldrive replaces the patchwork of spreadsheets, paper registers and ad-hoc tools schools rely on with one platform that serves four very different audiences.

• Schools onboard, manage academic sessions and terms, organize classes and arms, enroll students, and assign teachers.
• Admins generate fee records by class group or individual student, track payments, and approve parent-submitted payment proofs.
• Parents get a dedicated dashboard with their children's outstanding fees, payment history, and balances.
• Platform operators manage every school from a separate superadmin app — usage analytics, subscription billing, support tooling, and audit.

Architecture

Three apps in one monorepo, deployed independently on Railway. Separate services for API, worker, beat scheduler, Postgres and Redis keep workloads isolated.

• backend/ — FastAPI, async SQLAlchemy, Pydantic v2, Postgres, Redis, Celery (worker + beat). API, business logic and scheduled jobs.
• frontend/ — React, TypeScript, Vite, Zustand, React Query, Tailwind, Bun. School-facing app (admin, teacher, parent).
• superadmin/ — React, TypeScript, Vite, Tailwind. Platform-operator app.

Engineering choices worth noting

A few deliberate decisions keep the system correct, fast, and safe to iterate on.

• Money in kobo — every monetary value is an integer in the smallest currency unit (1 NGN = 100 kobo). No floats, no rounding drift, currency-aware formatting at the UI boundary only.
• OpenAPI-generated frontend types — FastAPI is the single source of truth; React apps consume types from /openapi.json so contract changes surface as TypeScript errors before they ever ship.
• Multi-tenancy via row-level scoping — every domain table carries school_id. Auth resolves the caller's school and every service-layer query is constrained at the boundary.
• Async-first backend — DB calls, email sends and external HTTP are non-blocking. Celery handles the genuinely long-running work (payslip emails, scheduled subscription invoicing, etc.).
• Per-term subscription billing — schools are billed for an upcoming term based on current student headcount, with adjustments for adds/archives before the cutover. Invoices are immutable once issued.
• Parent-submitted payment proofs — parents can upload a bank-transfer screenshot for admin approval and reconciliation in one click, no payment gateway required from day one.
• Audit log — every admin-impactful action (fee generation, waivers, archival, plan changes) writes an immutable audit row tied to the actor.

Domain modeling highlights

The data model mirrors how Nigerian schools actually run, not a generic SIS.

• Sessions and Terms — sessions span an academic year, three terms each. The active-term flag drives billing and fee generation.
• Classes and Arms — Class (e.g. Primary 4) splits into ClassArm (e.g. Primary 4 Gold). Students enroll into arms, not classes.
• Fee frequencies — per_session, per_term, monthly. Each generates a different number of records per student. Per-term fees are gated to the active term to prevent unbillable historical or future records.
• Payment claims — every payment proof is its own object with status (pending / approved / rejected) and a full audit trail.

What's next

V1 is feature-complete for self-service: schools can run end-to-end without an external payment integration. Currently in design for Monnify integration to add same-day parent fee settlement (T+0 to school NUBANs) and bulk staff payroll under a unified provider.