Dev-Collab
Team Collaboration PlatformA full-stack collaboration platform built around team-scoped authorization, transactional MongoDB operations, and asynchronous background jobs. Teams, projects, Kanban tasks, comments, notifications, and analytics come together in a pnpm monorepo with Vue 3, Express, MongoDB, Redis, and BullMQ.
August 2026 · Solo Project · ~4 weeks, full-time
Project Overview
Overview
Dev-Collab is a GitHub/Linear-inspired team collaboration platform — teams, projects, Kanban and list-based task management, threaded comments, task activity, notifications, analytics, and a platform-wide admin panel, built as a pnpm monorepo with a shared Zod schema package used by both the client and server.
Problem
Team collaboration becomes difficult to secure once permissions exist at more than one level. A user's platform role and their role inside a specific team are independent, while projects and tasks introduce additional ownership rules. The goal was to build those boundaries into the application from the start, while also handling asynchronous notifications, multi-document data changes, authentication, and production deployment without coupling everything to the API request path.
My Contribution
- Designed the two-tier authorization model separating platform roles from team membership roles
- Built the REST API, controllers, middleware, and Mongoose service layer
- Implemented MongoDB transactions for operations that modify multiple documents together
- Built the Vue 3 + Pinia frontend and audited the interface across 320px–2000px+ widths
- Implemented BullMQ/Redis notifications using a worker process separate from the API
- Implemented cursor and offset pagination based on the access pattern of each endpoint
- Set up production deployment with Heroku, MongoDB Atlas, Upstash Redis, and a separate worker dyno
- Built the GitHub Actions CI/CD pipeline that runs the backend test suite before allowing the Heroku deployment
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
Fixed the security hole without breaking the legitimate case of assigning yourself a task, confirmed with a dedicated regression test so it can't come back unnoticed.
Architecture & Data Flow
Project Walkthrough
Lessons Learned
Background jobs should have a clear failure boundary. BullMQ and Redis let the API hand off notification work to a separate worker, while graceful enqueue failure keeps optional asynchronous work from taking down the main request.
MongoDB transactions are valuable when one user action changes several related documents. They provide an atomic boundary for operations such as cascading deletes and coordinated status changes.
Pagination should match the access pattern rather than defaulting to one strategy everywhere. Cursor pagination works well for moving through changing datasets, while offset pagination remains useful where direct page navigation is more appropriate.
Authorization needs to be modeled around the actual action being protected. A permission that is valid for editing a task does not necessarily make sense for deleting it, and broad reusable checks can accidentally create privilege-escalation paths.
Building the project end to end deepened my experience with Vue 3, Express, MongoDB, Redis, and BullMQ, while deploying the system on Heroku and automating the release process with GitHub Actions connected the application code to the production workflow.