How to build a project & task manager with Bolt

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 bolt.new, checked August 2026.

The GitHub step comes before Bolt exists for you at all. Everything after it happens inside the browser tab Bolt opens, with no install.

1. 01

   A repository first, then the two rules in a file

   Bolt cannot open a folder or a zip, so the way in is a repository. Once it is imported, the first prompt writes down the two constraints everything after it depends on.

   PromptSet up the projectCopy

   This repository is a new React 18 + Vite + TypeScript project for a project and task manager. Add Tailwind and the Supabase JS client, with a typed client under src/lib reading VITE_SUPABASE_URL and the publishable key (the sb_publishable_… key that replaced the older anon key) from .env, and confirm .env is in .gitignore so neither value is committed. Then write a short PROJECT_NOTES.md fixing the vocabulary (project, board, column, task, subtask, comment, attachment, time entry, notification) and recording two standing rules to follow for the rest of this build. First: the board, list, calendar and timeline are four readings of one tasks table, so a new field is added once to the model and then shown where it is needed, never duplicated per view. Second: whether somebody may read a row is decided by a database policy rather than a filter in a component, and that applies to rows delivered by a realtime subscription as much as to a query. Start the dev server so I can see it boot.

   Keep those rules in the file rather than only in the chat. Clearing Bolt’s context between features is the cheapest way to keep prompts small, and anything that only ever lived in the conversation goes with it.

2. 02

   Talk the schema through in Plan Mode, then build it

   The one step where thinking is cheaper than generating. Plan Mode is the right tool here because a schema is exactly the kind of thing you want to argue about before any code exists that assumes it.

   PromptModel it once, and decide whose it isCopy

   Use Plan Mode for this one before writing anything. I want 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 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. In the plan, tell me two things before I approve it: how a task’s position within a column works, and which of two access shapes you are assuming: a project belongs to one person, or a project has members. Once I approve, write the migrations and seed three projects of deliberately different shapes: one with two boards, one with sixty tasks, one whose tasks have no due dates.

   Settle the access question in the plan rather than after it. Owner-only is a genuinely good answer for one person with several clients. Members is the answer if colleagues are coming. What you cannot afford is finding out in step 05, because changing it then means regenerating every policy and every view’s query, which on a token meter you feel twice.

3. 03

   The board, checked in the running app rather than described

   The first view, and the one where the preview is the whole test. It is the running app, so a card that does not stay put is something you can see in ten seconds.

   PromptBuild the boardCopy

   Build the Kanban board over the model. Columns in their stored order, task cards inside them in theirs, drag-and-drop within and between columns, a count on each column header, and a card showing priority, assignee, due date, and counts of subtasks and comments. On drop, write the new position and column to the database, then reconcile the screen against what came back rather than leaving a move the database refused. Tell me whether a drop rewrites one row or every card in the column, and what happens if two people reorder at the same moment. Then, in the preview: drag a card, reload, and confirm it is still where I put it, and open the app in a second browser window, drag a card in one, and say plainly that the other window does not update, because live updates are not in this prompt.

   Do that second-window check yourself rather than taking the answer. It costs you a minute, it makes the next step concrete, and it is the moment the difference between a board that draws state and a board that shares it stops being an abstraction.

4. 04

   The other three views, then the feed: two prompts, context cleared between

   Three views over the rows already on screen, then the subscriptions. These are unrelated enough that clearing context between them is worth doing, and cheap.

   PromptAdd the other three viewsCopy

   Two prompts, and clear your context between them. First, 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, 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, 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 screen re-fetching. Tell me which tables I have to enable realtime on in Supabase, since it is off by default. Then prove it in the preview: two windows, a card dragged in one, the list and the calendar moving in the other.

   Point the second prompt at the specific files the first one created rather than letting it read the whole project. Views and subscriptions barely overlap, and a prompt scoped to a handful of files is both cheaper on the token meter and less likely to come back having quietly rewritten a view you were happy with.

5. 05

   Sign-in, the rules, and the feed tested from another account

   Everything your team is working on is now in a database with a live feed on it. This is the prompt to read carefully rather than approve quickly.

   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, matching the access shape we settled in the step 02 plan. 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, tell me plainly that an assignee cannot open the board their task belongs to, and offer 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 repeating a subquery per policy. 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 safe default and it means an assignee picker returns one name. Then, in the preview with a second account, prove four things: it cannot read my project, cannot read my tasks, cannot read my time entries, and does not receive my rows through the realtime feed.

   The fourth check is the one that justifies the order of this whole build. A subscription is a read, and before the policies exist it delivers rows the ordinary query path would refuse, so a second account in a second window is the only instrument that finds it.

6. 06
   Destination

   The drawer, the dashboard, then publish

   Subtasks, comments with files, the timer, the notifications, the charts, then a day worked through with two accounts, and only then a deploy.

   PromptFinish the task, the dashboard, and rehearseCopy

   Finish the app. The task drawer: description, priority, due date, assignee, subtasks I can add and tick off, 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 on a task, one running entry per person, entries that survive a reload, and a database trigger totalling them onto the task so no component 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, overdue work, 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 with two accounts in two browser windows: create a project, fill a board, drag a card and watch the other window, assign across accounts and see the notification arrive, 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 with all of it. Then publish, and tell me which environment values I have to set on the host for the deployed app to find the database.

   That last question is the one to ask before you tell anybody the address. A build that cannot find its database URL and key does not show an error, it shows an empty board, which looks exactly like a tracker nobody has put anything in yet, and is the single most common way this app appears broken on day one.

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.

Pick a lighter model for the high-volume prompts above and save a stronger one for wherever the reasoning actually matters. That is the same token-budget logic as the rest of this page, applied to the app’s own AI calls instead of the build itself. When Bolt flags a missing secret, add the key through its secrets settings instead of pasting it into the chat, and keep every AI feature behind one server-side function so there’s only one key to manage.