Team Management System is a MERN team management system I built to give a team one place to plan, assign and track work, with what each person can see and do decided by their role: Admin, Manager or Team Member. It pairs a React and Redux Toolkit front end with an Express and MongoDB API secured by JWT and Bcrypt.
The problem
Small teams often run their work out of a chat thread and a shared spreadsheet. Tasks get assigned in messages that scroll out of sight, deadlines live in somebody's head, and nobody can tell at a glance who is overloaded. The manager ends up chasing status updates a tool should already show.
Moving everything onto one shared board fixes the visibility, then raises a second question: who may change what. A team member should move their own tasks along without being able to delete a project, and a manager should run a team without touching organisation-wide settings. I wanted permissions to shape the design from the first screen, instead of being added once the screens were built.
My role
I worked across the whole stack: the React front end built with Vite, Redux Toolkit and Material UI, the Express and Node.js API, the Mongoose schemas, and the authentication and permission model that ties them together. Much of the design work was deciding, for every screen and endpoint, which roles it belonged to and what each could do there.
Architecture and tech stack
Role checks enforced in Express middleware
Each user record holds one of the three roles, and the role travels inside the signed JWT. Protected routes pass through middleware that verifies the token and compares the role with what the route allows, so the rule is written once on the server. The React app also hides controls a user cannot use, but the API is the part that actually refuses a request.
Redux Toolkit for shared board state
A task appears in several places at once: its Kanban column, the assignee's dashboard, the deadline list and the analytics charts. Holding that in local component state would mean threading updates through the tree or refetching after every drag. With Redux Toolkit slices, a status change is dispatched once and every view reading that task updates from the same store, while async thunks keep each Axios call next to the state it changes.
Mongoose models shaped around assignment
A task references its project and holds an array of assigned members, which makes multi-member assignment and workload views possible without copying data between documents. Priority is a fixed set (Low, Medium, High, Urgent) validated in the schema, so the board and reports never meet a priority that does not exist. Statuses are the exception: because the Kanban columns are customizable, they are stored as data a team can edit.
Key features
- Three-tier role-based access: Admins, Managers and Team Members each get their own dashboard and their own allowed actions, checked on the server.
- A Kanban board with customizable statuses: teams set the columns to match how they actually work.
- Priorities and multi-member assignment: every task carries a Low, Medium, High or Urgent priority and can go to more than one person.
- Deadline tracking: due dates per task, with automated reminders before they pass.
- Approval-based onboarding: new members request to join and get access only once approved.
- Analytics and reports: completion rates, workload distribution and Chart.js progress charts, plus exportable reports for time tracking and project milestones.
Challenges and how I solved them
Keeping the interface and the API in agreement about roles
- Problem
- With three roles, the front end and back end drift apart easily: a button hidden from a member while its endpoint still accepts the call, or a manager shown an action the API then rejects.
- Solution
- I treated the server as the source of truth and kept one map of which role may perform which action. The Express middleware enforces it, and the React components read the same rules to decide what to render, so a permission changes in one place.
Onboarding without open signup
- Problem
- A team tool where anyone can register and see the board leaks data to strangers. One where an admin creates every account by hand stops being practical past a handful of people.
- Solution
- The request and approval flow sits between the two. Anyone can ask to join, but the account has no access until the request is approved, and only then does its role take effect. Passwords are hashed with Bcrypt before storage.
Analytics that respect the same boundaries
- Problem
- Dashboards are where permission bugs hide. A workload chart is fine for a manager viewing their own team, and a leak if a team member can call the same endpoint and see everyone else's numbers.
- Solution
- The analytics endpoints scope their queries by the caller's role before aggregating, so a member's charts come from their own tasks and a manager's from the projects they run. Chart.js only receives data the user could already see.
Results
Each role now gets a dashboard suited to its job. The one in the screenshot summarises team members, submitted reports, pending reviews, completed and pending tasks and active projects for the selected week, with a chart of reports per member and a split of work that is completed, in progress or awaiting review.
The same JWT and Bcrypt foundation, with a simpler two-role split, also runs MERN Mail, my email campaign manager with admin and user roles. Building three tiers here showed me that most of the effort in access control goes into deciding who should see what, more than into the code that enforces it.
What's next
Next would be an activity history on each task, showing who changed its status or assignment and when, and calendar export for deadlines. For role-based dashboards built a different way, with Admin and Customer roles enforced in plain PHP, see the PHP knowledge base management system.
