This was an internal ERP system built for work management and team collaboration. When I joined the project, the initial source and several architectural decisions were already in place and the system had been under development for roughly a month and a half. However, the main workflows were still incomplete: Task Management only had an early task-detail flow with Kanban still in progress, while Meeting Management had not yet been started.
I contributed to the project for approximately 12–14 months. My work was primarily focused on frontend implementation, while I also contributed to several important backend areas, including the authentication/session refactor and business rules around task workflows, authorization, real-time updates, and meeting scheduling. Requirements were typically passed down by the lead at a business or functional level; when they were incomplete, I was expected to clarify the scope, propose implementation approaches, and collaborate with the team on the final solution.
Main Functional Scope
The platform supported internal workflows such as:
project-based task management with Kanban, subtasks, priority, labels/tags, saved tasks, and multi-criteria filtering;
progress tracking derived from task/subtask state, with business rules that prevent inconsistent parent/subtask transitions;
near-real-time Kanban and task-detail updates through Socket.IO, combined with user-scoped notifications;
authorization based on role hierarchy, ownership, and project/task context;
meeting management with participant responses, conflict detection, UTC-based scheduling, and asynchronous reminders through BullMQ;
authentication and session management using access tokens, refresh tokens, and server-side session state.
Notable Technical Characteristics
Task workflow & real-time updates
Tasks stored both status and ordering within Kanban columns. Drag-and-drop operations were handled on the backend by swapping or shifting task positions, while the frontend refreshed only the affected columns. Real-time delivery was separated by purpose: project-scoped rooms for shared view updates and user-scoped rooms for notifications.
Authorization model
The frontend used a combination of global role information and project-context data to control visible actions. The backend enforced the same permissions at CRUD boundaries and filtered resources based on role, ownership, and hierarchy. Key actors such as task creators, assignees, project owners/managers, and higher-level roles remained included according to the business rules.
Authentication & session management
The authentication flow was refactored from a single-JWT approach to short-lived access tokens and longer-lived refresh tokens backed by server-side session records. This enabled per-session revocation and reduced reliance on a long-lived client-held token. On the client side, concurrent requests encountering token expiry reused a shared in-flight refresh operation before retrying.
Meeting scheduling & reminders
Meeting conflicts were checked against each user’s existing meetings when creating or updating a meeting and when participants responded. Reminder delivery used delayed BullMQ jobs, with lifecycle handling for rescheduling, cancellation, member removal, and retry on notification failure.