Eduversa
2024
Group Leader

Eduversa

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.

Scroll to explore

Project Highlights

Key metrics and achievements that define this project

0+
Technologies
0
Year Released
Group Leader
Role

Interested in This Project?

Explore the live demo, check the code, or reach out to discuss it

Full Case Study

See the delivery timeline, architecture notes, and decision tradeoffs.

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.

The Challenge

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.

The Solution

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.

Key Learnings

Gained expertise in enterprise-level authentication patterns, database optimization for high-traffic scenarios, and leading a development team through complex technical requirements.

Project Case Study Timeline

Delivery Decisions, Not Just Screenshots

A phase-by-phase record of how the work was scoped, built, and carried into production.

Problem / DiscoveryFeatured4 user roles

Role and workflow discovery

Framed the platform around four different user groups so admissions, faculty operations, and student workflows could be planned as separate responsibilities.

Technical Notes

The work started from permission boundaries and data ownership instead of from page layout, which reduced later RBAC churn.

ArchitectureFeatured

Authentication and RBAC architecture

Built the platform around NextAuth.js, MongoDB, and middleware-based permission checks so the ERP features shared one consistent access model.

Technical Notes

Context-based permissions and modular admin flows were treated as the main system design problem rather than as edge-case guards.

Maintenance

Operational implementation and maintenance path

Integrated complex forms, support bot workflows, and administrative operations in a way that could continue evolving after the initial delivery.

Technical Notes

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.

Outcome

The platform narrative now shows how enterprise-style permissions and admin operations were sustained beyond initial build-out.

Key Decisions

Engineering tradeoffs that shaped the build

A compact snapshot of the technical and product decisions that had the biggest impact on delivery.

Keep the frontend and operational backend separated

The platform had enough admissions and management behavior that some responsibilities were already centralized behind a separate API service.

Decision

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.

Fold all logic into the frontend repositoryKeep the frontend thin and backend-drivenMix both styles inconsistently per page

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.

Organize the experience around role-specific portals

Applicants, administrators, students, and faculty do not need the same mental model or screen hierarchy.

Decision

I treated the platform as one product with clearly separated role-specific surfaces instead of one overloaded dashboard.

One generic dashboard with conditional widgetsDistinct role-oriented flowsSeparate standalone apps per role

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.

Include operational admin tools, not just presentation pages

Admissions and institutional workflows create friction when the product stops at display pages and ignores admin handling.

Decision

I included practical admin tools in the product surface so the platform reflected real institutional operations.

Focus only on public or student-facing viewsShip partial admin supportBuild end-to-end operational surfaces such as applicant management and QR-based scanning

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.

Visual Showcase

A closer look at the shipped interface

This screen captures the production-facing design language, layout rhythm, and overall polish of the experience.

AssetProject Poster
Open Live Demo
Tech Stack

Built With

Scroll to explore technologies →

Next.js

MongoDB

NextAuth.js

Dialogflow

SCSS

AnkurOS·v0.134.7ready·--:--:--

Full-stack software engineer portfolio · Initialising

-- projects · -- certificates · -- blog posts

Loading0%
Loading AnkurOS