Overview
:::tip Use this page when You are trying to understand what Academia does, who it is for, and which documentation path to open first before diving into onboarding, architecture, or workflow-specific guides. :::
Academia is a multi-tenant academic project management platform built for universities and departments that need a clearer path from proposal intake to final defense. The public marketing experience lives at academia.et, while the product itself is split into a Next.js frontend and a NestJS backend API.
Fastest route through this guide
If you want the shortest useful read, move through these sections in order:
- Read What the platform covers to understand the operational scope.
- Read User roles to map the product to the people using it.
- Read Real workflow to understand how the platform behaves from setup through review.
- Continue to Onboarding and first setup if you are preparing a department rollout.
- Continue to Architecture if you want the frontend, backend, and tenant model behind the product.
What the platform covers
Academia is not just a dashboard shell. It coordinates real academic operations across several layers:
- Department and tenant onboarding
- Role-based dashboards and navigation
- Project proposals, project groups, and milestone templates
- Document submission, review, and feedback workflows
- Evaluation, defense scheduling, analytics, and notifications
- Multi-tenant routing, RBAC, and backend-enforced isolation
Architecture at a glance
Frontend application
The frontend repository is kubsamelkamu/Academia. It is a Next.js App Router application using a modern React and TypeScript stack.
- Next.js App Router + React + TypeScript
- Tailwind CSS v4 + shadcn/ui primitives
- Zustand for auth and UI state
- TanStack Query for server state
- Axios client with request and response interceptors
- Tenant-aware middleware that derives request context from the host
Backend API
The backend repository is kubsamelkamu/academia-backend-api. It provides the business rules and tenant-aware APIs behind the frontend.
- NestJS + TypeScript
- PostgreSQL + Prisma ORM
- Redis and queues for async/background processing
- Passport + JWT authentication
- Socket.IO for realtime updates
- Rate limiting, validation, and security middleware
How the two parts connect
At runtime, the frontend reads NEXT_PUBLIC_API_BASE_URL, attaches authentication headers, and forwards tenant context for upstream requests. The backend then resolves the tenant, applies guards and role rules, and routes the request into feature-specific modules such as:
authtenantprojectmilestoneevaluationnotificationanalyticscommunication
This is the core reason the docs should describe flows instead of isolated pages: the product is designed around coordinated frontend and backend behavior.
User roles
The platform revolves around role-based workspaces. The most visible roles in the frontend are:
- Department heads
- Coordinators
- Advisors
- Students
- Evaluators
Each role sees different navigation, dashboard cards, actions, and queues. For example:
- Students work in proposal, document, and milestone submission flows
- Advisors manage supervised projects, review items, schedules, and document feedback
- Coordinators monitor operations, assignments, and defense readiness
- Evaluators focus on assigned projects, scoring, and defense schedules
- Department heads manage high-level project oversight, templates, and institutional settings
Real workflow
The product can be understood as a three-stage operating model:
- Setup: establish department context, tenant identity, users, and workflow defaults.
- Delivery: run proposals, milestones, project collaboration, and document exchange.
- Review: coordinate feedback, evaluation, analytics, notifications, and defense preparation.
That same structure is what this documentation should keep mirroring.
For the real first-run sequence, start with Onboarding and first setup. That page documents the actual department-head-first onboarding flow supported by the current frontend and backend.
Best page by reader type
| If you are... | Start here next | Why |
|---|---|---|
| A department head or coordinator preparing rollout | Onboarding and first setup | It explains the real first-run order for activating the platform. |
| A reader trying to understand role boundaries | Roles and dashboards | It maps each role to dashboards, actions, and responsibilities. |
| A reader trying to understand how the system is built | Architecture | It explains how the frontend, backend, tenant model, and infrastructure fit together. |
| A reader trying to understand the full operating flow | Project lifecycle | It shows the end-to-end path from proposal intake to evaluation and defense. |
Product snapshots
The frontend repository already includes public-facing screenshots that help make the docs more concrete.
Landing and product entry
Student workspace
Coordinator workspace
Advisor workspace
Evaluator workspace
What this documentation should do next
The strongest next improvements are now clearer:
- Map each role to its responsibilities and screens
- Explain tenant-aware local development and API setup in one place
- Document the project lifecycle from proposal through defense using real platform flows
- Add more screen-backed docs pages for dashboards, documents, scheduling, and evaluation
Best next reads
- Onboarding and first setup for the real department-head-first rollout sequence.
- Architecture for the system view behind the product.
- Roles and dashboards for role-by-role ownership and UI context.
- Project lifecycle for the end-to-end operational journey.