CLIENT DELIVERY · VERTICAL ERP

School Management ERP — Student, Fees, Attendance & Administration

A role-based school management ERP covering students, teachers, parents, attendance, examinations, fees, transport, library and administration, built for K-12 and coaching institutions.

Delivered on CodeIgniter + MySQL with real screens and a 6:39 walkthrough—proof of vertical ERP experience, plus a clear path to modernize.

CodeIgniterMySQLMulti-roleFeesAttendanceExamsSMS
Discuss Custom School ERP Watch 6:39 demo Legacy modernization
Industry
K-12 / coaching institutes
Type
School management ERP
Roles
Admin · Teacher · Student · Parent · Librarian
Stack
CodeIgniter · MySQL · Bootstrap Neon
Proof
Screens · 6:39 product demo
VERTICAL ERP CASE STUDY

Custom school ERP development — and a path to modernize legacy school software.

Who this is for. Private K-12 schools, coaching institutes, education groups and teams modernizing CodeIgniter/PHP or spreadsheet-driven ops—not buyers chasing a “best school ERP in India” comparison list.

What you get. Evidence of a delivered multi-role school desk (students, attendance, exams, fees, transport, library, dormitory) plus a clear modernization path to API-first, mobile and AI-enabled platforms.

Searches this page answers: school ERP software · school management ERP · custom school ERP development · school fee management · attendance · parent portal · legacy school ERP modernization

Real system. Real screens. Real implementation. A production school ERP delivered on an established PHP/CodeIgniter + MySQL stack—technology appropriate to the client’s environment rather than a fashionable rewrite for its own sake. Today, the same business domain can be modernized with an API-first architecture while preserving workflows and the student data model.

Why this school ERP case study still matters

This project demonstrates an approach that remains relevant: model the institution’s actual workflows instead of forcing school operations into generic CRUD screens.

  • Student lifecycle, academic management, attendance, examination, fee collection
  • Parent communication, teacher operations, library, transport, dormitory, administration
  • The technology changes. The domain architecture and workflow modeling remain fundamental.

Who this is for

Private K-12 schools

Students, academics, attendance and fee management.

Coaching institutes

Batches, attendance, exams and fees.

Multi-campus / education groups

Shared architecture with role-based access (modern multi-tenant design as an extension).

Legacy modernization

Migrate CodeIgniter/PHP or spreadsheet workflows to a modern stack.

The problem

School administration frequently spans multiple disconnected processes: admissions, student records, attendance, examinations, fees, communication and staff operations. When these live in spreadsheets, registers or separate applications, the same student information is repeatedly entered and reconciled.

Admission → Student Record → Class / Section
  → Attendance → Examination → Fees → Parent Communication

Constraints

Delivery stayed inside the client’s stack and environment. CodeIgniter/MySQL was the appropriate plane for this engagement—not a claim that every new school build must use PHP.

School ERP vs school management software

In practice the terms are often interchangeable. “School management software” commonly emphasizes daily academic/admin operations; “ERP” generally implies broader integration across finance, transport, library, hostel and other organizational functions.

This project combines academic workflows with fees, accounting, transport, library and dormitory operations—so “ERP” is credible, not just SEO wording.

See the school ERP in action

6:39 product walkthrough — working-system video. Portfolio write-up with screenshots; the dedicated watch page owns VideoObject.

Open watch page → YouTube →

School ERP admin dashboard with event calendar and student teacher parent attendance stat tiles

Running academic session in the header, event calendar widget and live counters for students, teachers, parents and today’s attendance.

Role-based school ERP

SCHOOL ERP
                           │
       ┌──────────┬────────┼────────┬──────────┐
       ▼          ▼        ▼        ▼          ▼
     Admin      Teacher  Student   Parent    Librarian
       │          │        │        │          │
   Operations  Academic  Learning  Comms     Library

Each role gets a portal/menu suited to the job—admin runs the institution; teachers handle academics and marks; students and parents see learning/communication surfaces; librarians manage library workflows.

flowchart TB
  subgraph roles [Portals]
    AD[Admin]
    TE[Teacher]
    ST[Student]
    PA[Parent]
    LI[Librarian]
  end
  CI[CodeIgniter application]
  DB[(MySQL)]
  roles --> CI --> DB
  CI --> SMS[SMS hooks]
  CI --> RPT[Reports]
Role portals → CodeIgniter → MySQL; notifications and reports as application surfaces.

Student information management

  • Student records by class and section
  • Admission, promotion and document workflows
  • Board/section tabs (CBSE / State Board in this deployment)
  • Bulk admit and export to Excel/PDF
School ERP student management dashboard with class and section records

Per-class student lists with section tabs, bulk admit, promotion and export.

Attendance management

  • Daily attendance by class/section and date
  • Attendance reporting surfaces
  • Dashboard counters for today’s attendance
  • Parent notification hooks as an extension path
School ERP manage attendance form with class section and date selector

Examination management

  • Examinations, subjects, marks and grade scales
  • Tabulation sheets and question papers
  • Optional SMS mark delivery
  • Result communication to roles that need them
School ERP exam marks management with exam class section and subject selectors

Exam list, grade scales, marks entry, tabulation and optional SMS mark delivery.

Fee management & financial integrity

  • Single and mass invoices
  • Payment status and receipts
  • Expense categories beside academic modules

Fee receipt immutability

Once a fee payment is posted, the original receipt should not be silently modified. Corrections should follow an explicit adjustment or reversal workflow—proper financial-system thinking, not a soft edit on a paid row.

School ERP create student payment invoice form with paid status and cash method

Accounting sits beside academic modules, not in a separate tool.

Library, transport & dormitory

  • Library — books, issue/return, student records
  • Transport — routes and transport records
  • Dormitory / hostel — accommodation and student allocation

These sit on the admin sidebar with academic and accounting modules—supporting a true school ERP scope.

From admission to next academic session

A school ERP becomes useful when modules share a common student identity rather than operating as independent applications. This implementation addresses consistent student IDs across modules and term rollover.

Admission → Student Profile → Class / Section
  → Attendance → Fees → Exams → Results → Promotion
  → Next Academic Session

Academic year & term rollover

End of Academic Year → Promotion Rules
  ├── Class 1 → Class 2 · Class 2 → Class 3 · …
  → New Academic Session
  (preserve history · keep student identity · avoid corrupting past terms)

Term rollover scripts for class promotion preserve historical records, create new class/section relationships and keep the student identity stable across years.

SMS & school communication

Implemented in this project: SMS hooks and optional SMS mark delivery without duplicate contact lists.

School Event (Attendance · Exam · Fee · Announcement)
        → Notification Layer → SMS
        (Modern extension: Email · WhatsApp · Push)

Multilingual settings

Admin includes multilingual settings—valuable for India when parent notifications, fee reminders, attendance alerts and announcements need English, Hindi or regional languages. Treat language expansion as configuration/product work on top of the notification layer.

Parent & teacher experience

In this delivery: Parent and Teacher are first-class roles with portal menus. A modern school ERP often expands parent access to attendance, marks, fees, announcements, timetable, homework, documents and notifications—market demand is high; label deeper parent-app UX as modernization unless shown on these screens.

Architecture

SCHOOL USERS
                         │
       ┌───────┬─────────┼─────────┬────────┐
       ▼       ▼         ▼         ▼        ▼
     Admin  Teacher   Student    Parent  Librarian
               │
        CodeIgniter Application
       ┌───────┼────────┐
       ▼       ▼        ▼
    Academic  Finance  Admin Ops
               │
             MySQL → Notifications / Reports / SMS

Technology stack

CodeIgniterMySQLBootstrap NeonAJAX loginSession authMulti-roleSMS

CodeIgniter is useful technical evidence—not the primary buyer keyword. Selecting an established PHP stack for the client’s environment is part of solution architecture.

Production engineering

  • Consistent student ID across fee and exam cycles
  • Term rollover / class promotion scripts
  • Fee receipt immutability after payment posted
  • SMS optional path without duplicate contact lists
  • Role-based menus so portals do not share Super Admin chrome

Custom school ERP vs off-the-shelf software

Off-the-shelf ERPCustom school ERP
Fixed workflowsInstitution-specific workflows
Fixed reportsCustom reports
Limited integrationsAPI integrations
Vendor-defined rolesCustom RBAC
Standard fee rulesCustom fee structures
Vendor roadmapYour roadmap / controlled architecture

Custom development makes sense when the institution’s processes are materially different from a standard school ERP subscription—or when a legacy desk must be modernized without losing data history.

From legacy ERP to a modern school platform

Modernization possibilities (not claimed as shipped features of this CodeIgniter build):

Legacy ERP (CodeIgniter / PHP)
  → Architecture Audit → API Extraction → Data Migration
  → Modern Frontend / PWA → Mobile → Cloud / Observability
  → AI / Automation

If we modernized this ERP today

  • Frontend — Next.js/React, responsive PWA, mobile-first dashboards
  • Backend — NestJS/FastAPI, REST APIs, events where real-time matters
  • Data — PostgreSQL + Redis
  • Communication — SMS, WhatsApp, email, push
  • Mobile — parent/teacher apps and student portal

Connects to Full-Stack, Custom CRM/ERP, SaaS, Cloud DevOps, Production Rescue and AI & Data Engineering.

Future AI-enabled school ERP (potential)

Labeled as potential modernization / future capability—not features of the original delivery unless separately implemented.

  • AI admissions / parent assistant — requirements, fees, attendance, next exam
  • AI analytics — attendance anomalies, fee-risk, performance trends
  • Document processing — admission docs, certificates
  • Automation — fee reminders, attendance alerts, exam notifications

What I built

CodeIgniter ERP delivery — modules, schema, multi-role portals and admin UX from requirements to a working system documented with screenshots and a 6:39 demo.

RequirementsDomain modelCodeIgniter modulesMySQL schemaMulti-role portalsFees & examsTerm rolloverSMS hooks

Outcomes

  • Delivered/restored school desk with role-specific portals
  • Academic + fees + ops modules on one student identity
  • Production rules for term rollover and fee receipt integrity
  • Portfolio evidence: screenshots + 6:39 working-system video
FAQ

School ERP & school management software questions

Custom school ERP development and legacy modernization—not PBX/insurance FAQ leftovers.

School ERP software is an integrated platform for student records, academic operations, attendance, examinations, fees, parent/teacher portals and often transport, library and hostel—sharing one student identity instead of disconnected spreadsheets and apps.

Core modules typically include admissions/students, classes/sections, attendance, examinations/marks, fees/accounting, role portals (admin, teacher, student, parent), and often library, transport, dormitory and notifications. This case documents those surfaces with screenshots and a 6:39 walkthrough.

Terms are often used interchangeably. “School management software” commonly emphasizes daily academic/admin operations; “ERP” implies broader integration across finance, transport, library, hostel and organization-wide functions. This project combines academic workflows with fees, accounting, transport, library and dormitory.

Yes. This build includes manage-attendance flows by class, section and date, with counters on the admin dashboard.

Yes. Single and mass invoices, payment status and expense categories sit beside academic modules. After payment is posted, fee receipts are treated as immutable—corrections need explicit adjustment/reversal workflows.

Yes. Exam lists, grade scales, marks entry, tabulation sheets, question papers and optional SMS mark delivery are part of the documented exam module.

Yes via a parent role/portal in the multi-role design. Modern extensions can deepen parent apps (attendance, fees, exams, announcements)—labeled separately from what this CodeIgniter delivery shipped.

Yes. This system uses Admin, Teacher, Student, Parent and Librarian portals with role-based menus.

Yes. SMS hooks and optional SMS mark delivery are documented. Modern extensions can add email/WhatsApp on the same notification layer.

Yes. Typical path: architecture audit → API extraction → data migration → modern frontend/PWA → cloud/observability → optional AI/automation—while preserving student identity and academic workflows. See Full-Stack, Custom CRM/ERP and Production Rescue.

Yes. The domain model and workflows are the durable asset; NestJS/FastAPI + PostgreSQL + Next.js/PWA is a common modernization target when the institution is ready—without forcing a rewrite before requirements are clear.

Yes with tenancy, billing and isolation design. See SaaS development. This case study is a delivered school desk, not a public multi-tenant SaaS login.

As a modernization path: admissions/parent assistants, attendance anomalies, fee-risk signals, document extraction and notification summaries—clearly labeled as future capability unless implemented. See AI & Data Engineering.

School type (K-12/coaching), campuses, must-have modules (fees, exams, parent portal), current stack (CodeIgniter/PHP/spreadsheets), and whether you need greenfield custom ERP or legacy modernization. Screenshots beat a long RFP. Email hello@unifiedpbx.in.

Need a custom school ERP—or to modernize an old one?

Share school type, campuses, must-have modules and whether you are on CodeIgniter/PHP, another ERP or spreadsheets. The first reply names greenfield vs modernization boundaries.

Discuss Custom School ERP