Led the development of a massive educational ERP platform featuring strict Role-Based Access Control (RBAC) for Admins, Faculty, Students, and Applicants. Engineered a multi-provider authentication system using NextAuth.js linked to a MongoDB cluster. Integrated a Dialogflow-powered support bot and built complex, multi-step administrative forms for seamless data management.
Key metrics and achievements that define this project
Explore the live demo, check the code, or reach out to discuss it
Full Case Study
A role-heavy education platform where the main challenge was coordinating multiple user flows, auth paths, admin operations, and backend dependencies without turning the UX into a maze.
Managing complex role hierarchies and permissions across 4 user types while ensuring data security and maintaining a smooth UX. The platform needed to handle thousands of concurrent users during admission periods.
Implemented a robust RBAC system with middleware guards and context-based permissions. Used MongoDB aggregation pipelines for complex queries and Redis for session management. Built a modular form system with validation at multiple levels.
Gained expertise in enterprise-level authentication patterns, database optimization for high-traffic scenarios, and leading a development team through complex technical requirements.
A phase-by-phase record of how the work was scoped, built, and carried into production.
Framed the platform around four different user groups so admissions, faculty operations, and student workflows could be planned as separate responsibilities.
The work started from permission boundaries and data ownership instead of from page layout, which reduced later RBAC churn.
Built the platform around NextAuth.js, MongoDB, and middleware-based permission checks so the ERP features shared one consistent access model.
Context-based permissions and modular admin flows were treated as the main system design problem rather than as edge-case guards.
Integrated complex forms, support bot workflows, and administrative operations in a way that could continue evolving after the initial delivery.
The project record already ties the implementation to multi-step admin forms and support tooling, which makes the maintenance story concrete without inventing post-launch business metrics.
The platform narrative now shows how enterprise-style permissions and admin operations were sustained beyond initial build-out.
Key Decisions
A compact snapshot of the technical and product decisions that had the biggest impact on delivery.
The platform had enough admissions and management behavior that some responsibilities were already centralized behind a separate API service.
I worked with the split architecture and kept the frontend responsible for the role-specific product surface while backend actions continued to flow through the dedicated API service.
Impact: The product could support more operational workflows without forcing every concern into the Next.js app.
Tradeoff: A separate backend increases integration points and makes frontend reliability partially dependent on another deployment.
Visual Showcase
This screen captures the production-facing design language, layout rhythm, and overall polish of the experience.
Scroll to explore technologies →
Applicants, administrators, students, and faculty do not need the same mental model or screen hierarchy.
I treated the platform as one product with clearly separated role-specific surfaces instead of one overloaded dashboard.
Impact: The platform feels closer to an actual ERP-style tool than to a single-user education portal.
Tradeoff: This increases navigation and state complexity, especially when roles have materially different workflows.
Admissions and institutional workflows create friction when the product stops at display pages and ignores admin handling.
I included practical admin tools in the product surface so the platform reflected real institutional operations.
Impact: The project reads as a systems build, not only a marketing or portal frontend.
Tradeoff: Operational tools are less glamorous than public-facing pages and demand more careful workflow design.
