← Back to Projects

SchoolIEP

Full-stack Individualized Education Plan (IEP) management platform for student records, goals, parent coordination, and progress reporting.

A-Tier · Public Repository Portfolio / academic project · No public live deployment

1. The Problem

Schools and support teams need structured ways to maintain student records, create and track Individualized Education Plans, define learning goals, involve parents, and produce period-based progress reports. When this information lives in disconnected documents, meetings and reporting become harder to keep consistent.

SchoolIEP was built as a software-engineering / portfolio project to model these multi-stakeholder education workflows in a full-stack application — without claiming institutional certification, FERPA/compliance status, or production school deployment.

2. The Solution

Verified capabilities supported by repository models, routes, and frontend components:

Student records — first/last name, studentId, grade, schoolId, disabilities, special needs
IEP lifecycle — status (draft → active → inactive/expired), start/end dates, next meeting, notes
Learning goals — linked to an IEP; categories (academic, behavioral, social, physical, communication); status and progress percentage; observations
Parent profiles — linked to a student; relationship type; consent flag; contact fields
Progress reports — period (quarter / semester / year), overall progress, summary, observations; linked to an IEP
JWT authentication — Bearer-token middleware protecting API workflows
Domain REST modules — students, parents, IEPs, goals, progress
React dashboard UI — IEP dashboard, student management, goals, progress report views

No public live deployment is listed. Local setup is the intended review path.

3. System Architecture

Monolithic full-stack design.

┌──────────────────────────────┐
│     SchoolIEP Frontend       │
│  React + Vite                │
│  Dashboard components        │
└──────────────┬───────────────┘
               │ REST API
               ▼
┌──────────────────────────────┐
│     Express.js Backend       │
│  Node.js · JWT middleware    │
│  student / parent / iep      │
│  goal / progress routes      │
└──────────────┬───────────────┘
               │
               ▼
      ┌────────────────┐
      │ MongoDB        │
      │ + Mongoose     │
      │ Student        │
      │ Parent         │
      │ IEP            │
      │ Goal           │
      │ ProgressReport │
      └────────────────┘

Relationships: Goal → IEP (ObjectId ref); Parent → Student (ObjectId ref); ProgressReport → IEP (ObjectId ref).

4. My Contribution

SchoolIEP is presented as an individual portfolio / academic software project. The public codebase and documentation reflect full-stack work across:

Domain data modelling (Student, Parent, IEP, Goal, ProgressReport)
REST API modules for each domain entity
JWT authentication middleware
React frontend screens for dashboard, students, goals, and progress
Setup and project documentation

5. Key Technical Decisions

Separate Goal and ProgressReport collections

Why: Goals and period reports have different lifecycles and query patterns; referencing an IEP keeps them independent while still linked.

Trade-off: More collections to manage versus embedding everything inside the IEP document.

MongoDB + Mongoose with ObjectId refs

Why: Flexible schemas for education data that evolves (disabilities lists, observations); straightforward population of related entities.

Trade-off: Application-level consistency for cross-document integrity; IEP currently stores studentName rather than a strict Student ObjectId in the model as written.

JWT Bearer middleware

Why: Stateless protection for SPA + API; simple authenticate middleware checks Authorization header.

Trade-off: No rich RBAC roles in the middleware itself (unlike ClinicOS’s multi-role model); auth is present/absent based on a valid token.

React + Vite dashboard components

Why: Fast iteration for multi-screen education workflows without a heavy frontend framework.

Trade-off: UI is functional for portfolio demonstration; polish and depth vary by screen.

6. How the System Works

Authentication

Client sends Authorization: Bearer 
  → authMiddleware verifies JWT with JWT_SECRET
  → req.user attached → protected route handlers run

IEP + goals flow

Create Student (+ optional Parent linked by studentId)
  → Create IEP (draft) for student / school
  → Activate IEP
  → Add Goals (category, target, progress %)
  → Update goal status / observations over time

Progress reporting

Select IEP + period (quarter / semester / year)
  → Write summary, overall progress, observations
  → Store ProgressReport linked to IEP

7. Current Limitations

Portfolio / academic project — not a certified institutional IEP system or evidence of regulatory compliance.
No public live deployment — repository and local execution are the proof path.
Lightweight auth model — JWT verification is present; fine-grained multi-role RBAC is thinner than ClinicOS.
Schema simplicity — some links use names/IDs rather than fully normalised multi-entity graphs everywhere.
UI depth — core screens exist; not every admin/reporting edge case is fully polished.
Testing evidence — primarily manual / documentation-driven rather than large automated suites.

8. Repository & Demo Status

No public live deployment is currently listed. Clone and run locally using the README setup instructions (backend default port 5001).

Open Public Repository ↗ Back to Projects

Scope & Disclaimer

SchoolIEP is an academic/software engineering project. It should not be represented as a certified institutional records platform or as evidence of compliance with educational privacy or special-education regulations.