How to build a project & task manager with Claude Code

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 and claude.com, checked August 2026.

Nothing here is worth memorizing. These four just need to exist on your machine. From step 01 on, you say what you want and Claude Code runs the commands.

1. 01

   Boot it, then write down the two rules the build leans on

   By the end of this you have an empty app talking to your own database, and a CLAUDE.md holding the two sentences that decide how the next five steps go.

   PromptSet up the projectCopy

   Set up a new React 18 + Vite + TypeScript project with Tailwind and the Supabase JS client. Read VITE_SUPABASE_URL and the publishable key (the sb_publishable_… key, which replaces the older anon key) from .env, and add .env to .gitignore in the same step so neither value reaches GitHub. Add a typed Supabase client under src/lib, then write a short CLAUDE.md describing the stack and fixing the vocabulary for a project and task manager (project, board, column, task, subtask, comment, attachment, time entry, notification) and recording two standing rules. First: the board, the list, the calendar and the timeline are four readings of one tasks table, never four features with their own ideas of what a task is, so any new field is added once to the model and then surfaced in whichever views need it. Second: whether somebody may read a row is decided in the database rather than in a component, and that includes rows pushed by a realtime subscription. A live feed is a read like any other.

   Put both rules in the file, not just in this message. The second one is the one that gets quietly broken: filtering a list in the component is the natural thing to write, it works perfectly while you are the only account signed in, and the failure it causes is invisible until somebody else logs in.

2. 02

   Model it once, and decide now whether anybody else is coming

   The step that determines what the rest of the build costs. Nothing is being displayed yet, which makes this the cheap moment to find out your projects do not nest the way you assumed.

   PromptModel it once, and decide whose it isCopy

   Write the data model as Supabase migrations, with no authentication yet. 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 just 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 with deliberately different shapes: one with two boards, one with sixty tasks so I can see what a list of real size looks like, one with tasks that have no due date at all, and tell me before you write it which of these two access shapes you are building for: a project belongs to one person, or a project has members. I want to pick, because it changes the policies in step 05 and it is expensive to change afterwards.

   Answer that question out loud before you let it proceed. One owner per project is a real, useful product and much less work. A shared workspace needs a membership table from this migration onwards, and retrofitting one means rewriting every rule, every view’s query, and the live feed at the same time, which is exactly the change nobody wants to make in month three.

3. 03

   The board, and a card that stays where you dropped it

   The first view, and the one with a genuinely awkward piece of work in it. Dragging looks visual. The part that matters is that the new order is written down.

   PromptBuild the boardCopy

   Build the Kanban board over the model: columns across the screen in their stored order, task cards inside them in theirs, drag-and-drop to move a card within a column and between columns, and a column header showing its count. When a card is dropped, write the new position, and the new column, to the database, then reconcile against what comes back rather than leaving the screen showing a move the server refused. Make the card itself carry a priority, an assignee, a due date, and a count of its subtasks and comments. Then show me two things by running them: drag a card, refresh the page, and confirm it is still where I put it, and open the same board in a second browser window, drag a card in one, and tell me plainly whether the other window updates, because I have not asked for live updates yet and I want to see for myself that it does not.

   That last instruction is worth the extra minute. Watching the second window stay stale is what makes step 04 concrete rather than an abstraction, and it is the moment most people realise a project tracker is not a form over a database.

4. 04

   The other three views, then make all four live

   A list, a calendar and a timeline over the rows the board is already showing, then the subscriptions that stop any of them going stale. This is where the "one model" rule earns back the time it cost.

   PromptAdd the other three viewsCopy

   Add the remaining three views over exactly the same tasks, with no new fields and no second source of truth. A list view: sortable and groupable by column, priority, assignee and due date, filterable, with editing in place and subtasks nested under their parent. A calendar view: a month grid by due date, with a clearly labelled place for the tasks that have none rather than dropping them. A timeline view: a bar per task from its start date to its due date, with an honest treatment of tasks missing one or both rather than an invented range. Then add realtime: subscribe to changes on projects, boards, columns, tasks, comments, time entries and notifications, and have every view update from the same cache so a change arrives everywhere at once instead of being re-fetched per screen. Tell me which tables I have to enable realtime on in Supabase, since it is off by default, and then prove it: two windows, drag a card in one, and the list and the calendar in the other move without a reload.

   Ask what the timeline does with a task that has no start date, and do not accept “it defaults to the created date” without thinking about it. A bar that quietly invents a range is worse than a task that honestly does not appear, because you will make plans on it.

5. 05

   Sign-in, then the rules, including the ones the live feed needs

   Everything your team is working on is now in the database, and a live feed hands rows out. Two things happen in this step, and the second is the one people skip.

   PromptAdd auth and the access rulesCopy

   Add Supabase Auth with email and password: sign-up, login, logout, a persisted session, a profile row per account created by a trigger, and a useUser hook. Then row-level security on every table, built for the access shape I chose in step 02. One owner: a person reads and writes their own projects and everything under them, and a task is additionally readable and updatable by its assignee, and if I picked that, tell me straight out that an assignee will not be able to open the board their task sits on, and offer the smallest change that fixes it. Members: a membership row grants access, every policy on boards, columns, tasks, comments and time entries checks it through a SECURITY DEFINER function rather than a subquery per policy, and only an owner may add or remove members. Either way: explicit WITH CHECK on every insert and update, notifications readable only by their addressee, and a deliberate decision about the accounts table, since reading only your own row is the default and means an assignee picker gets one name back. Then prove four things as a signed-in account: a second account cannot read my project, my tasks, or my time entries, and (this one matters most) subscribe to the tasks table as that account and show me the live feed does not push my rows to it.

   That fourth check is the whole reason the live updates went in first. A subscription is a read, and if your policies are not in place the feed happily delivers rows the query path would have refused. It is the least-visible hole in an app of this shape, and the only way to know is to open a second account and watch.

6. 06
   Destination

   The task’s inner life, the dashboard, and a day in two browsers

   Subtasks, comments with files, the timer that totals, notifications, and the numbers over the top. Then the part most builds skip: use your own tracker as two different people at once.

   PromptFinish the task, the dashboard, and rehearseCopy

   Finish the app. The task drawer first: description, priority, due date, assignee, subtasks I can add and tick off, and a comment thread with file attachments. For those attachments, do not make the storage bucket public. Use signed URLs with an expiry, generated for somebody allowed to see the task, and tell me what that costs in complexity so I can decide. 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 screen is doing that arithmetic. Then notifications raised by triggers on assignment and on comment, arriving live in a dropdown. Then a dashboard: tasks by status, what is overdue, workload by assignee, and where tracked time went, with the headline counts computed server-side and scoped to the signed-in account. Then walk me through a working day using two accounts in two browser profiles: create a project, fill a board, drag a card and watch the other window, assign across accounts and see the notification arrive, start 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 with two real accounts in separate browser profiles rather than by switching your own. Almost every mistake left in an app of this shape is invisible to one signed-in person, and the two that always turn up are a view that shows rows it should not and a live feed that pushes them.

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.

Each prompt above picks the model that fits the job. As a rule of thumb, that is Haiku for high volume, Sonnet for everyday writing, and Opus for deeper reasoning. Model names move faster than this page does, so check the current list in the Claude docs (linked in the references below) before you build. Send every one of these prompts through that same ai function, so one key and one set of rules governs all of them.