1) Project kickoff & goals
We started with a clear goal: build APNOU, a LinkedIn-style learning platform that brings together students, teachers, parents, schools and colleges. Key outcomes were:
Unified homepage feed, discovery of courses/institutions.
Role-based accounts (Student / Teacher / Parent / School / College).
Teachers can add marks; parents can view progress.
AI tutor to recommend study plans and send automated reports.
Strong privacy & permission controls for student records.
We defined an MVP that delivered the minimum features above and left advanced analytics, video classes, and broad SIS integrations for later.
2) Architecture & tech decisions
Early design choices shaped everything:
Frontend
React for web, React Native (or Flutter) for mobile so UI parity and code reuse.
Component-driven UI: feed, profile, institution page, teacher grade-entry.
Backend
Node.js + Express/NestJS microservices pattern. Separate services for Auth, User Management, Marks & Records, Notifications, AI.
PostgreSQL as the system of record (relational fits schools/classes/grades). Use JSONB for flexible profile fields.
Redis for caching and rate-limiting.
Object storage (S3) for media (profile pictures, documents).
Message queue (RabbitMQ / Redis Streams) for asynchronous tasks: email/report generation, notifications, AI-analysis jobs.
AI & analytics
A separate Python FastAPI microservice for the AI tutor and analytics. Started with rule-based logic + lightweight ML models and designed to plug-in larger LLMs later.
Auth & integrations
Google OAuth for Teacher and Parent (optionally all users).
JWTs for session tokens and refresh-token rotation patterns for security.
Deployment & ops
CI/CD pipelines (GitHub Actions) and Kubernetes (or managed serverless like Cloud Run) for deployments.
Monitoring (Prometheus / Grafana) + error tracking (Sentry).
3) Implementation phases (high level timeline)
Discovery & wireframes (2–3 weeks) — wireframes for homepage, profiles, teacher grade UI, parent dashboard.
Core backend + auth (3–4 weeks) — user model, roles, org model (school/college), Google OAuth.
Frontend MVP (4–6 weeks) — feed, search, profile pages, teacher grade entry flows.
Marks & permissions (2–3 weeks) — teacher entry UI, institutional permission rules, parental access linking.
Notifications & email reports (2–3 weeks) — in-app push (FCM), weekly email generation.
AI tutor (prototype, 3–4 weeks) — simple analytics, rule-based recommendations, scheduled analysis job.
Testing, security review & pilot launch (3–4 weeks) — pilot with 1–2 schools, iterate on UX and permission flows.
Production hardening & launch — monitoring, backups, scaling playbooks.
4) Product choices that mattered
Treat institutions (school/college) as first-class entities with their own admin dashboards.
Enforce separation of concerns: institutions own marks/records — only accessible with explicit permissions.
Make parent linking explicit and consent-based (parent must be invited/linked by school or student).
Design feed algorithm to surface institution announcements, course highlights, and AI recommendations differently by role.
Keep AI features opt-in initially and transparent (show how suggestions were generated).
Challenges we faced — detailed, with how we solved them
Below are the major problems we hit, why they happened, and the concrete solutions we implemented.
1) Complex role & permission matrix
Problem: Many roles with overlapping permissions (teacher vs. school admin vs. parent vs. student) caused bugs, data leaks, and confusing UX (who sees what).
Symptoms: Parents could sometimes see more data than they should; teacher could not edit marks for some classes; school admins needed bulk control.
Fixes / Mitigations:
Built an explicit, auditable permission model (RBAC + ACL). Every sensitive API call checks both role and institution-level permission.
Added an access log table (who viewed which student record and when).
Created a permissions UI in the institution admin panel with clear toggles (View Marks, Edit Marks, Export Data, External Sharing).
Added automated tests and end-to-end scenarios for role flows.
Lesson: design permissions up front; retrofitting permissions is error-prone.
2) Data privacy & minors
Problem: Handling minors’ data requires explicit consent and careful defaults. Parents expected full insight; schools wanted control.
Symptoms: Confusion over whether parents should automatically view marks; reluctance from schools to allow external views.
Fixes / Mitigations:
Implemented a parental consent flow: parents are linked only after explicit invite and consent. Schools can require admin approval.
Defaults: student data private; parents must be linked; schools decide external visibility of aggregated metrics.
Added features: data export, delete requests, and a clear privacy page. Logged all consent actions.
Consulted legal counsel (or at least documented the need) before sweeping rollouts in new regions.
Lesson: conservative defaults (privacy-first) and clear consent flow reduce risk and build trust.
3) Integrating Google OAuth + multiple auth methods
Problem: Users wanted Gmail sign-in while others wanted local accounts. Keeping identity consistent and linking multiple auth methods per user was tricky.
Symptoms: Duplicate accounts (same email with password & Google), session confusion, broken password resets.
Fixes / Mitigations:
Implemented identity linking: allow users to link multiple credentials to one user record (email/password + Google).
Standardized on canonical email as primary identifier, but verified emails before linking.
Added clear UX: “Link your Google account” and “Sign in with Google” explanations.
Carefully handle account recovery flows.
Lesson: allow multiple login methods but keep a single canonical user entity beneath them.
Log in or sign up for Devpost to join the conversation.