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.
Problem
Eduversa was not a single-interface product. It had to support applicants, students, faculty, and administrators, each with different workflows, while still behaving like one coherent platform rather than a bundle of unrelated dashboards.
Timeline
Workflow mapping
I framed the system around distinct user groups first so permissions, data flows, and navigation patterns were derived from actual operational differences.
The repository contains separate role-driven surfaces and user-type based navigation flows.
Auth and backend integration
I worked within a split architecture where authentication and many business actions already depended on shared services outside the main frontend repository.
The repo includes NextAuth Google configuration and multiple calls to eduversa-api.onrender.com.
Operational tooling
The product went beyond generic portals by including applicant-profile management, scanner-based operational flows, and richer admin pages.
The repo contains admin applicant management pages and a QR-scanner flow.
Stability posture
Because the product depends on an external hosted backend, I treated service wake-up and responsiveness as part of the frontend operating model.
The repository includes a PulseKeeper utility that periodically pings the backend.
Key Decisions
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.
Tradeoff: A separate backend increases integration points and makes frontend reliability partially dependent on another deployment.
Impact: The product could support more operational workflows without forcing every concern into the Next.js app.
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.
Tradeoff: This increases navigation and state complexity, especially when roles have materially different workflows.
Impact: The platform feels closer to an actual ERP-style tool than to a single-user education portal.
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.
Tradeoff: Operational tools are less glamorous than public-facing pages and demand more careful workflow design.
Impact: The project reads as a systems build, not only a marketing or portal frontend.
Architecture
The frontend is a Next.js application that coordinates multiple role-specific experiences instead of serving one generic account area.
Authentication is integrated through NextAuth with Google provider support, while many application actions call an external backend hosted at eduversa-api.onrender.com.
The product also includes operational helpers such as pulse-keeping for the backend, QR-based admin workflows, and dedicated admin management surfaces for admissions-related tasks.
The project demonstrates leadership on a multi-surface product: authentication integration, role-specific experience design, admin workflow construction, and practical coordination with a separately hosted backend.
Eduversa shows that I can lead through system complexity: multiple user types, operational workflows, external backend dependencies, and institutional UX all had to stay coherent at once.