Dev-Collab

Team Collaboration Platform

A full-stack team collaboration platform — teams, projects, a Kanban task board, comments, notifications, and analytics, built on a two-tier authorization model with a background job queue.

August 2026 · Solo Project · ~4 weeks, part-time

Live Demo Source Code

Project Overview

Overview

Dev-Collab is a GitHub/Linear-style team collaboration app built on a pnpm monorepo — an Express + MongoDB backend, a Vue 3 frontend, and a shared Zod schema package consumed by both, so the same validation rules run on the client and the server. It covers teams, projects, a Kanban/list task board, threaded comments, a per-task activity timeline, in-app notifications backed by a real background job queue, a team-scoped analytics dashboard built on MongoDB aggregation pipelines, and a separate platform-wide admin panel.

Problem

Team collaboration tools bundle a lot of subtle authorization logic — a user's platform-wide role and their role inside any one team are genuinely independent, and getting that wrong is a real security bug, not just a UX inconsistency. The goal was to build that correctly from the ground up, including finding and closing an actual privilege-escalation path along the way, rather than bolt permissions on after the fact.

My Contribution

Designed the two-tier (platform-role vs. per-team-role) authorization model and its nested-resource access middleware
Built every REST endpoint and Mongoose service layer, including multi-document transactions for cascading deletes
Wired up the Vue 3 + Pinia frontend, including a full 320px–2000px responsive audit and fix pass
Set up the BullMQ/Redis notification worker as a process fully separate from the API
Handled the full production deployment: Heroku, MongoDB Atlas, Upstash Redis, Vercel, a custom domain, and a CI/CD pipeline that gates the Heroku release on a passing test suite

Implementation

Key Features

Two independent permission systems: global platform roles and per-team roles
Multi-document Mongo transactions for cascading deletes and status changes
BullMQ + Redis background worker, isolated from the API's request path
Cursor- and offset-paginated APIs, chosen per access pattern
123 backend tests against a real in-memory MongoDB replica set
Fully responsive Vue 3 + shadcn-vue interface, audited from 320px to 2000px+

Tech Stack

Frontend

Vue 3TypeScriptTailwind CSS

Backend

Express.jsMongoDBRedisBullMQZod

Technical Challenges

Solution

Added a narrower, assignment/delete-only permission check (team-admin OR project-owner, no assignee branch) while deliberately keeping edit assignee-inclusive, since editing a task you're assigned to is legitimate.

Result

Closed the escalation path without breaking the legitimate workflow, verified with a dedicated regression test.

Architecture & Data Flow

Project Walkthrough

Lessons Learned

A memory-only access token means every hard page reload relies entirely on the refresh cookie — worth single-flighting the refresh call from day one, not after the first race-condition bug report
CSS Grid's implicit tracks default to content-based sizing, not clamped to the container — an explicit grid-cols-1 is a one-line fix, but only once you've actually rendered the page in a real browser to see it happen
Two permission concepts that sound similar (a user's platform role vs. their role inside one team) need to be enforced as genuinely separate checks, or you end up with a real escalation path instead of just confusing code

Project Overview

Overview

Problem

My Contribution

Designed the two-tier (platform-role vs. per-team-role) authorization model and its nested-resource access middleware
Built every REST endpoint and Mongoose service layer, including multi-document transactions for cascading deletes
Wired up the Vue 3 + Pinia frontend, including a full 320px–2000px responsive audit and fix pass
Set up the BullMQ/Redis notification worker as a process fully separate from the API
Handled the full production deployment: Heroku, MongoDB Atlas, Upstash Redis, Vercel, a custom domain, and a CI/CD pipeline that gates the Heroku release on a passing test suite

Implementation

Key Features

Two independent permission systems: global platform roles and per-team roles
Multi-document Mongo transactions for cascading deletes and status changes
BullMQ + Redis background worker, isolated from the API's request path
Cursor- and offset-paginated APIs, chosen per access pattern
123 backend tests against a real in-memory MongoDB replica set
Fully responsive Vue 3 + shadcn-vue interface, audited from 320px to 2000px+

Tech Stack

Frontend

Vue 3TypeScriptTailwind CSS

Backend

Express.jsMongoDBRedisBullMQZod

Technical Challenges

Solution

Result

Closed the escalation path without breaking the legitimate workflow, verified with a dedicated regression test.

Lessons Learned

A memory-only access token means every hard page reload relies entirely on the refresh cookie — worth single-flighting the refresh call from day one, not after the first race-condition bug report

CSS Grid's implicit tracks default to content-based sizing, not clamped to the container — an explicit grid-cols-1 is a one-line fix, but only once you've actually rendered the page in a real browser to see it happen

Two permission concepts that sound similar (a user's platform role vs. their role inside one team) need to be enforced as genuinely separate checks, or you end up with a real escalation path instead of just confusing code

Project Overview

Overview

Problem

My Contribution

Implementation

Key Features

Tech Stack

Technical Challenges

01Any team member could self-assign a task, which then satisfied an assignee-inclusive "can manage" check and unlocked delete — a real privilege-escalation path, not just a design smell.

02The access token lives in memory only (never localStorage, for XSS safety), so two pages firing requests at the same moment a token expired could each trigger their own refresh call, racing two token rotations and forcing a spurious logout.

03Modal dialogs and data tables silently overflowed their own containers at narrow widths — a shadcn-vue primitive used a bare CSS grid with no explicit column count, so its implicit track sized to content instead of clamping to the dialog's own max-width.

04Task-assignment and comment notifications go through a BullMQ/Redis queue processed by a separate worker — a Redis outage or a crashed worker shouldn't be able to take the API down with it.

Architecture & Data Flow

Project Walkthrough

Lessons Learned

Project Overview

Overview

Problem

My Contribution

Implementation

Key Features

Tech Stack

Technical Challenges

01Any team member could self-assign a task, which then satisfied an assignee-inclusive "can manage" check and unlocked delete — a real privilege-escalation path, not just a design smell.

02The access token lives in memory only (never localStorage, for XSS safety), so two pages firing requests at the same moment a token expired could each trigger their own refresh call, racing two token rotations and forcing a spurious logout.

03Modal dialogs and data tables silently overflowed their own containers at narrow widths — a shadcn-vue primitive used a bare CSS grid with no explicit column count, so its implicit track sized to content instead of clamping to the dialog's own max-width.

04Task-assignment and comment notifications go through a BullMQ/Redis queue processed by a separate worker — a Redis outage or a crashed worker shouldn't be able to take the API down with it.

Architecture & Data Flow

Project Walkthrough

Lessons Learned