How to build a project & task manager with v0

Rule of thumb: if work arrives from a dozen other systems, if clients need guest access, if people live in the mobile app, or if somebody in compliance needs an audit trail, rent. Those are real products and none of them is a weekend of describing. If what you want is your team’s work in one place, in the views you find useful, with fields that match how you talk about it, and a bill that does not grow every time you hire, that is the half worth owning. Two things to weigh either way. This template ships with a project belonging to one person, and the shared-workspace version is an addition described in the steps below rather than something already built. And the paid tier you would replace is more than a paywall over four views: the automations, the integrations, and the phone in somebody’s pocket.

* Ignore the 500 MB database limit. Tasks and comments are text, and text is small. Two other free-tier lines matter. The 1 GB of file storage is what attachments spend, and it goes faster than you expect once people start dragging screenshots onto cards. And a free project pauses after a week of inactivity, which for a tracker means the week your team quietly drifts back to a spreadsheet. Pro, from $25/mo, ends the pause, takes file storage to 100 GB and egress to 250 GB (then $0.09 per GB), and keeps a daily backup for 7 days.

What separates the two columns is which way the bill moves. Renting gets more expensive with every person who joins. Owning costs the same at thirty people as at three, and the only line that shifts is whichever AI model you choose to call. One of those two shapes suits a team that is growing, and growing is the only thing anybody is trying to do.

Prices and rates from supabase.com, developex.com, v0.app, v0.app and vercel.com, checked August 2026.

The database step is the one worth not skipping once your screens need real data. Everything else here takes a couple of minutes, and after that you’re just describing what you want.

1. 01

   Sketch the board and the drawer, because that is what v0 leads with

   The board, a task drawer, and a project list with invented content, in one chat. The point is to look at how a card and a task actually read before anything is stored anywhere.

   PromptSketch the tracker screensCopy

   Build the core screens for a project and task manager in Next.js, using placeholder content for now. A project list. A Kanban board with columns and draggable cards, each card showing a title, a priority, an assignee, a due date, and counts of subtasks and comments. A task drawer that opens over the board with a description, subtasks, a comment thread, and a start/stop timer. A dashboard shell with room for charts. Include one column holding twenty cards so I can see what a real one looks like rather than three tidy examples, and show me the empty state for a board with no tasks. Keep it responsive. Somebody will open this on a phone to move one card.

   Use Design mode for the visual corrections rather than describing them. On a board, the drop targets, the card density and how a column reads on a narrow screen are most of the product, and those are exactly what Design mode is for.

2. 02

   Connect the database, then retire every placeholder at once

   The hard stop. Add the integration from the project menu, then ask for one schema and the routes over it, and take the invented data out of the screens you just looked at before you build a single new view.

   PromptModel it once, and decide whose it isCopy

   A Supabase integration is now connected to this project. Design one schema and the routes that read it, then take the placeholder content out of the screens already built. Projects with a name, description, colour and an owner. Boards belong to a project. Columns belong to a board with a stored position. Tasks belong to a column with a title, description, priority, status, due date, an optional start date for the timeline, an assignee, a stored position within the column, and an optional parent task so a subtask is a task with a parent. Comments belong to a task with an author and an optional attachment path. Time entries belong to a task and a person with a start, an end and a duration. Notifications belong to a person. Seed three projects of deliberately different shapes: one with two boards, one with sixty tasks, one whose tasks have no due dates. Write server-side routes for the project list, a board with its columns and tasks, and a single task, and wire the existing screens to them. Before you start, state which of two access shapes this schema assumes (a project belongs to one person, or a project has members), and if it is members, put that table in this migration.

   Get this done before another view exists. Everything after it reads real rows, and a calendar or a timeline generated against invented tasks will have quietly decided what a due date and a start date are, which is a decision you then have to find and undo in two places instead of making once here.

3. 03

   Make the board’s dragging real, in its own chat

   The board exists and looks right. What it does not yet do is remember. This is a small chat with one genuinely fiddly thing in it.

   PromptBuild the boardCopy

   New chat, for the board’s writes. Make the drag-and-drop real: on drop, a server-side route persists the card’s new position and its new column, and the screen reconciles against what the route returns rather than keeping an optimistic move the database refused. Be explicit in the diff about how reordering works: whether a drop rewrites one row or every card in the column, and what happens if two people reorder at the same moment. Keep the columns and cards rendering in their stored order rather than whatever order the query happened to return. Then let me check it: drag a card, reload, confirm it stayed, and open the board in a second window, drag a card in one, and tell me plainly that the other does not update, since realtime is not in this chat.

   Ask for the reorder strategy in words as well as code. Rewriting every card in a column on every drop is the version that arrives naturally, reads perfectly, and gets slow and contentious on the first board that has two hundred cards on it.

4. 04

   The other three views, and a live feed, in a chat each

   Three views over the rows the board already shows, then the subscriptions that keep them honest. Separate chats, because you will restore a version in one of them.

   PromptAdd the other three viewsCopy

   Two chats. First, the remaining three views, reading exactly the same tasks through the same routes, with no new fields anywhere: a list view sortable and groupable by column, priority, assignee and due date, filterable, editable in place, with subtasks nested under their parent. A calendar view on a month grid by due date, with a labelled place for tasks that have none rather than dropping them. A timeline view drawing a bar from a task’s start date to its due date, handling a missing start or end honestly instead of inventing a range. Second chat, live updates: subscribe to changes on projects, boards, columns, tasks, comments, time entries and notifications, feeding one shared cache so a single change reaches all four views rather than each one re-fetching. Tell me which tables I have to enable realtime on in Supabase, since it is off by default. Then prove it: two windows, a card dragged in one, the list and the calendar moving in the other.

   Keep the subscriptions in their own chat and their own pull request. It is the change most likely to need restoring, and you do not want the three views travelling backwards with it, which is exactly what happens when one long chat carries both.

5. 05

   Auth and access rules, in a separate chat and its own pull request

   Everything your team is working on now sits in a database with a live feed pointed at it. Separate chat, separate pull request, read on its own.

   PromptAdd auth and the access rulesCopy

   New chat, for authentication and access rules. Add email-and-password sign-up, login, logout, a persisted session, and a profile row per account. Then row-level security on every table, matching the access shape declared back in step 02. Owner-only: a person reads and writes their own projects and everything beneath them, and a task is additionally readable and updatable by its assignee, and if that is the shape, say so plainly in the pull request, including that an assignee cannot open the board their task belongs to, plus the smallest policy change that would let them. Members: a membership row grants access, and every policy on boards, columns, tasks, comments and time entries checks it through one security definer function rather than a repeated subquery. Either way: explicit with-check clauses on inserts and updates, notifications readable only by their addressee, and a deliberate decision about the accounts table, since reading only your own row is the safe default and it means an assignee picker returns one name. Then prove four things as a second signed-in account: it cannot read my project, cannot read my tasks, cannot read my time entries, and is not pushed my rows by the realtime subscription.

   Give this its own pull request rather than stacking it on the views. Of every change in this build, the access rules are the one you will most want to read back as a single self-contained diff in six months, when somebody asks you what stops one client seeing another client’s board.

6. 06
   Destination

   The drawer’s insides, the dashboard, then merge and deploy

   Subtasks, comments with files, the timer, the notifications, the charts, a day worked through the app with two accounts, and only then the merge that publishes it.

   PromptFinish the task, the dashboard, and rehearseCopy

   Last chat. Fill in the drawer: description, priority, due date, assignee, subtasks I can add and tick, and a comment thread with file attachments served through signed URLs with an expiry, generated for somebody allowed to see the task, rather than a public bucket. Then time tracking: a start/stop timer, one running entry per person, entries that survive a reload, and a database trigger totalling them onto the task so no route or component is doing that arithmetic. Then notifications raised by triggers on assignment and on comment, arriving live in a dropdown. Then the dashboard: tasks by status, overdue work, workload by assignee, and where tracked time went, with the headline counts computed server-side and scoped to the signed-in account rather than a query the browser could widen. Then walk a full day with me using two accounts in two browser profiles: create a project, fill a board, drag a card and watch the second window, assign across accounts and see the notification land, run a timer and confirm the task total moves, post a comment with a file and check what the other account can and cannot open, and confirm the dashboard agrees.

   Do the rehearsal before the merge, not after. This is the chat that turns your tracker into something people would actually keep work in, and a merge into the branch your Vercel project deploys from is the moment a mistake stops being yours alone.

Review the access rules (row-level security policies) on every table. For each one, tell me in simple terms who can view, add, edit, and delete records, confirm that people can only reach their own data while the right roles can reach more, and flag anything left open that shouldn’t be.

One rule outranks the rest here: the database service key and any AI provider key live on the server and nowhere else: not in the app your team downloads, and not in a public repository. Treat either one that escapes as burned, and replace it the same day.

All eight serve the app well enough that speed is not the deciding question. Three others are. Does the plan permit commercial use, given Vercel’s Hobby tier does not and a tracker your company works in is commercial by any reading. Does it publish from a private repository, given what this code sits beside. And does a deep link resolve for a browser that has never seen your site, because a URL pointing at one task is the link your team will share most.

Build me a server-side ai function (a single place, with my provider key on it and nowhere else) plus a screen where I can paste notes, a message, or a brief. Send the text to that function and get back proposed tasks: a title, a one-line description, a suggested priority, an assignee only where the text names somebody, and a due date only where the text gives one. Show them as a reviewable list I can edit and delete from, then create into a board I pick, with nothing written until I press create. Where the text is vague, say so rather than inventing a date: “next sprint” comes back as no date and a note saying why, not a Friday you chose.

Add a “summarise the week” action on a project that gathers what changed over a date range I choose (tasks created, tasks that moved column, tasks completed, due dates passed unmet, and comment activity) and sends only that activity summary to my ai function, with no attachment contents. Have it return a short written update in three parts: what moved, what is stuck, what is due next. Compute every count with a query and let the model only do the writing, so no figure is invented. Print the date range on the result, and where a section is empty say nothing happened rather than padding it.

Add a panel listing tasks that look stalled (no column change, no comment, and no tracked time for a number of days I set), sending each one’s title, age, column and last activity to my ai function for one line on what appears to be blocking it and one suggested next step. Send no attachment contents and no comment text beyond the most recent. Order by how long each has been still, show the actual dates beside each row so I can check the reasoning, and where there is too little activity to say anything useful, have it say so rather than guess.

Add an estimate suggestion on a new task. Query my own completed tasks for similar ones (same board, similar title, same priority) with their tracked totals, send those durations and titles to my ai function, and have it return a suggested range plus one line naming which past tasks it drew on. Show the sample size beside the suggestion, and refuse to suggest anything from fewer than five comparable tasks rather than guessing. It is a suggestion in a field I can overwrite, never a value written automatically.

Add a panel where I ask a question about my own projects in ordinary words and get an answer with the numbers behind it. Have my ai function turn the question into a read-only query over my own data, run it under my own access rules so it can never reach a project I cannot see, and use the model only to explain the result. Show the query it ran and the figures it used under every answer, state the period and the number of rows involved, and where the sample is too thin to support the answer, say so.

v0 doesn’t ship its own model for these prompts, so you bring an API key for whichever provider you want, and v0 writes the route that calls it. Start with a cheap model while you’re still iterating on the prompt itself, then swap in a stronger one for the version that ships, and keep every AI feature behind that one route so there’s only one key to rotate.