# Build brief — a focused alternative to Draftroom

> **Verdict:** Partly, if you narrow it · **Buildability:** 55/100 · **Category:** Project Management
> **Source:** https://www.canitbevibecoded.com/draftroom
> Independent editorial assessment from Can It Be Vibe Coded? Not affiliated with, endorsed by, or derived from Draftroom. Verify current pricing and capabilities before acting.

## Context

**Draftroom** — Creative project management for marketing agencies managing content, feedback, approvals, and delivery. It currently costs $99/mo.

A competent coding agent can rebuild Draftroom's core agency workflow in a focused implementation: clients, projects, tasks, file versions, contextual feedback, review queues, approvals, client review links, delivery tracking, and workspace permissions. The gap is not the CRUD screens; it is production-grade collaboration, notification reliability, permission edge cases, file handling, mobile review polish, and the accumulated project history that makes a shared agency system dependable every day.

This brief describes a focused, single-operator replacement for the part of Draftroom that is genuinely reproducible. It is deliberately narrower than the product it replaces, and it says so in writing. Build the useful core; do not pretend to have rebuilt the rest.

## What you are building

Create a client and project, assign content work, upload versioned files, collect internal and client feedback, approve the right version, and mark the work delivered without splitting the workflow across separate tools.

- Track tasks, dependencies, and status across boards you maintain yourself.
- A responsive interface with real empty, loading, success, and error states.

## Requirements

### Functional

- Node.js.
- Supabase project with PostgreSQL, Auth, and Storage.

### Data and integrations

- Environment variables for Supabase and database credentials.

Each of these needs a real account, credential, or quota. Set them up before writing feature code.

### Non-functional

- Accessibility: semantic markup, labelled controls, visible focus, and reduced-motion support.
- Security: server-side secrets, validated input, and no credentials in the client bundle.
- Reliability: retries with backoff on external calls, and a clear failure state when a provider is down.
- Portability: the operator can export their data and leave without losing it.

## Implementation brief

Build a working web app called Draftroom, an opinionated creative project-management system for marketing agencies and high-volume content teams.
Use Remix + TypeScript + Tailwind CSS + Prisma + PostgreSQL; use Supabase Auth for login and Supabase Storage for uploaded files, with every secret in .env.
Make it multi-tenant: users belong to a workspace through Membership records and must never be able to read or mutate another workspace's data.
Use this core data model: User, Workspace, Membership, Client, Project, Task, TaskAssignee, TaskReviewer, FileAsset, FileVersion, Comment, Approval, ReviewLink, Notification, and ActivityEvent.
Workspace roles are OWNER and MEMBER; external clients normally use scoped review links instead of full workspace accounts.
Users can create clients, create projects under clients, invite teammates, archive clients/projects, and see only work inside their workspace.
Tasks need title, description, status, priority, assignees, reviewers, startDate, dueDate, deliveryDate, createdAt, updatedAt, attachments, comments, and activity.
Use the workflow BACKLOG → TODO → IN_PROGRESS → IN_REVIEW → APPROVED → DELIVERED and allow drag-and-drop Kanban movement plus a compact list view.
Add a content calendar that plots tasks by due/delivery date and lets users open the same task detail drawer from calendar, list, or Kanban.
Build My Work for the signed-in user; show assigned tasks grouped by status and sort by due date, then delivery date, start date, updatedAt, then title.
Task detail should open as a fast drawer and support editing fields, assignees/reviewers, comments, attachments, version history, approvals, and activity without losing board context.
Files belong to tasks/projects; every replacement upload creates FileVersion v0, v1, v2... while preserving old versions and clearly marking the current version.
Comments can be attached to a task or a specific file/version and have INTERNAL or CLIENT_VISIBLE visibility so team discussion can remain private.
Reviewers need a Review queue for IN_REVIEW work and can Approve or Request Changes with a required/optional comment; approval state and decision history must be visible.
Generate secure expiring /review/:token links for selected files; the mobile-first review page needs no client account and allows only the permissions encoded in the link: view, comment, approve/request changes.
Review links must reveal no unrelated workspace/project data, use random non-guessable tokens, support revocation/expiry, and rate-limit write actions.
Record task creation/edits, assignments, status moves, uploads, new versions, comments, review decisions, link creation/revocation, and delivery in an ActivityEvent timeline.
Add in-app notifications for assignments, mentions, review requests, comments, approvals, requested changes, and approaching due dates; mark read/unread.
Dashboard should show active projects, overdue work, due soon, waiting for review, approved/ready to deliver, recent activity, and quick links into the filtered work.
Use optimistic UI for common mutations, skeleton/loading states, helpful empty/error states, responsive layouts, keyboard-accessible controls, and a dense calm interface closer to Linear/WhatsApp Web than enterprise PM software.
Create routes for /login, /app, /app/my-work, /app/calendar, /app/clients, /app/clients/:clientId, /app/projects/:projectId, /app/review, /app/settings/members, and public /review/:token.
There must be no platform super-admin system: do not create /admin, /super-admin, impersonation, global user/workspace management, super-admin DB roles, middleware, APIs, or related code.
Deliberately exclude billing/subscriptions, attendance/payroll, time tracking, resource planning, Gantt charts, AI agents, email/calendar integrations, SSO, advanced analytics, white-labeling, and Frame.io-style frame-accurate media annotation.
Seed one demo agency with 5 members, 3 clients, multiple projects, realistic marketing tasks, several file versions, comments, review decisions, notifications, and activity so every flow is testable immediately.
Add Prisma migrations, indexes/constraints for tenant safety and common filters, secure server-side authorization helpers, file validation, and tests for cross-workspace access plus review-link permissions.
Add a README with setup, env vars, Supabase configuration, migration/seed commands and run/deploy instructions; then run lint/typecheck/tests/build and fix failures.
Before finishing, verify the complete loop works: create workspace → client → project → task → assign → upload versions → internal feedback → review → client link → approval/changes → delivered.

## Delivery standard

- Inspect the repository first, then write a short implementation plan before writing code.
- Deliver the smallest complete end-to-end workflow first; every primary control must work against persisted data.
- Use real validation and storage; never substitute fake dashboards, decorative controls, hard-coded success states, or mock integrations.
- Include responsive layouts plus genuine empty, loading, success, validation, and failure states.
- Keep secrets server-side in environment variables, provide .env.example, and never commit credentials or user data.
- Add structured logs around every external call and return actionable errors without leaking sensitive details.
- Write unit tests for the core logic and one automated test of the main user journey.
- Finish with a README covering setup, architecture, data location, backups, tests, deployment, and known limitations.

## Acceptance criteria

- [ ] A clean install starts the app using only the README and .env.example.
- [ ] The primary journey works from first visit through saved result, reload, edit, export, and deletion where applicable.
- [ ] Invalid input, missing configuration, provider failure, and an empty database each have a usable state.
- [ ] The interface works at 390px and 1440px, is keyboard navigable, and shows visible focus on every control.
- [ ] Tests, type checking, linting, and a production build all pass with no ignored failures.
- [ ] No part of the interface implies a live integration, security guarantee, or scale capability that was not actually built and verified.

## Non-goals

Do not build these, and do not claim to have replaced them:

- Production-hardened real-time and notification behavior across many simultaneous users.
- Years of edge-case handling around client permissions, review links, files, revisions, and approvals.
- Polished mobile review and collaboration behavior that non-technical clients can use without training.
- Operational history, project context, and team habits already accumulated inside an existing Draftroom workspace.
- Enterprise features such as SSO, advanced reporting, white-labeling, onboarding, and support.

## What you still own after launch

- Run migrations, backups, restores, and dependency updates.
- Test the critical journey after every model, API, or hosting change.
- Monitor failures and fix the edge cases a first prompt will miss.

## Risk

**Manageable.** A personal version is realistic if you test the critical journey and keep reliable backups.

Editorial confidence in this assessment: high. No reviewed project implementation is linked yet.

---

Generated by [Can It Be Vibe Coded?](https://www.canitbevibecoded.com) · Full report: https://www.canitbevibecoded.com/draftroom