Can Draftroom be vibe coded?
Creative project management for marketing agencies managing content, feedback, approvals, and delivery.
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.
Jump to the build brief ↓Legacy-calibrated assessment
Checked Aug 2026
What you pay today, before any DIY hosting
high editorial confidence
Tracked separately from the pricing check
Buildability by layer
Screens, forms, and focused interactions
The repeatable job the product performs
Availability and legality of required data
Uptime, queues, support, and maintenance
Security, compliance, and user confidence
The achievable core
- 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.
The parts a prompt cannot buy
- 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
- Permissions, presence, and shared workflows are difficult to simplify.
- Years of history, configuration, and habits make migration costly.
Build, switch, or keep paying
Narrower, with trade-offs
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.
Use the build brief ↓No checked option yet
Compare the prior art below or build only the workflow you need.
$99/mo
The basic mechanics are straightforward to recreate, but an agency does not pay for a Kanban board in isolation. It pays for a shared workflow that designers, account managers, founders, freelancers, and clients can trust every day. Reliable permissions, version history, review links, approval state, notifications, mobile behavior, file handling, and the cost of moving active client work make the hosted product more valuable than a focused implementation clone once the whole team depends on it.
Visit Draftroom ↗Why people still pay
The basic mechanics are straightforward to recreate, but an agency does not pay for a Kanban board in isolation. It pays for a shared workflow that designers, account managers, founders, freelancers, and clients can trust every day. Reliable permissions, version history, review links, approval state, notifications, mobile behavior, file handling, and the cost of moving active client work make the hosted product more valuable than a focused implementation clone once the whole team depends on it.
Permissions, presence, and shared workflows are difficult to simplify.
Years of history, configuration, and habits make migration costly.
The last 20 percent is sync, migration fidelity, speed, and edge cases.
The brief
Context, requirements, acceptance criteria, non-goals, and the full production standard — as Markdown, ready for any coding agent.
Build brief — a focused alternative to Draftroom
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? · Full report: https://www.canitbevibecoded.com/draftroom
You still own the product
- 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.
Projects built from this idea
No reviewed implementation has been linked for Draftroom yet. A submission is evidence for review, not automatic proof that the whole product was replaced.
Built a version of Draftroom?Submit the project as evidence for this report.
Before you start
Can Draftroom be vibe coded?
Partly, if you narrow it. 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.
What can an AI coding agent reproduce from Draftroom?
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.
What will a DIY Draftroom replacement still be missing?
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; Permissions, presence, and shared workflows are difficult to simplify.; Years of history, configuration, and habits make migration costly.
What do I still own after building a Draftroom alternative?
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.