How to build a project & task manager with Lovable

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 docs.lovable.dev, checked August 2026.

Only the first three are needed to start, and none of it touches your computer. From here, you describe what you want and Lovable builds it in the browser.

1. 01

   Attach the database before you ask for a single screen

   A board designed against data that does not exist yet is a board you rebuild the day it does. Attach the database first, and get the two rules into the conversation while it is still short enough for them to stick.

   PromptSet up the projectCopy

   Connect my Supabase project before building any screens at all. Then set up a project and task manager, and hold two rules for the rest of this project. First: the board, the list, the calendar and the timeline are four ways of showing one tasks table, so a new field goes on the task once and then appears in whichever views need it, never four versions of the same idea. Second: whether somebody may see a row is decided in the database rather than in a screen, and that includes rows arriving through a realtime subscription. Use these words consistently: project, board, column, task, subtask, comment, attachment, time entry, notification. Confirm the connection is live, then tell me which of those two rules changes how you will design the tasks table, before you design it.

   That closing question earns its extra exchange. It is the cheapest way to find out now whether the model Lovable has in mind gives a task a stored position and a real parent reference, or whether the board is planning to remember the order itself, and only one of those two survives a second person opening the same board.

2. 02

   Design the tables, and answer the question about other people

   The one step where getting it right is worth more than getting it visible. Everything you build afterwards reads what you settle here.

   PromptModel it once, and decide whose it isCopy

   Design the tables, with no sign-in 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. Time entries belong to a task and a person with a start, an end and a duration. Notifications belong to a person. Add sample data with deliberately different shapes: one project with two boards, one with sixty tasks, one whose tasks have no due dates. Before you build any of it, tell me which of these two you are designing for: a project belongs to one person, or a project has members, and if it is members, put that table in now rather than later.

   Answer that before you send the next message, and bookmark the version once the tables exist. Changing the access shape later is the one change in this build that touches everything at once, and remember that restoring code in Lovable does not roll back your database, so a bookmark and a clear decision are worth more here than anywhere else.

3. 03

   The board, and proving a dropped card is written down

   The part Lovable is fastest at, and the part where a preview is most likely to flatter you. Dragging that looks right and forgets is the specific failure to check for.

   PromptBuild the boardCopy

   Build the Kanban board over those tables. Columns across the screen in their stored order, task cards inside them in theirs, drag-and-drop within a column and between columns, a count on each column header, and a card showing priority, assignee, due date, and how many subtasks and comments it has. When a card is dropped, save the new position and column to the database and then reconcile the screen against what came back, rather than leaving a move on screen that the database refused. Then, in the preview, do two things for me: drag a card, reload the page, and show me it is still where I put it, and open the preview in a second browser window, drag a card in one, and confirm out loud that the other window does not update, because I have not asked for live updates yet.

   Use Select elements for the visual corrections here rather than describing them. A board is mostly spacing and drop targets, and the difference between a column you can drop into comfortably and one you fight is exactly the sort of thing that is quicker to point at than to word.

4. 04

   The other three views, then make the whole thing live

   Three more views over the rows you can already see, then the subscriptions that stop any of them going stale. Bookmark before this one.

   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, editable in place, with subtasks nested under their parent. A calendar view: a month grid by due date, with a clearly labelled place for tasks that have none rather than dropping them. A timeline view: a bar per task from its start date to its due date, treating a missing start or end honestly instead of inventing a range. Then turn on realtime: subscribe to changes on projects, boards, columns, tasks, comments, time entries and notifications, and have all four views update from the same shared cache so one change arrives everywhere rather than each screen re-fetching. Tell me which tables I need to enable realtime on in Supabase, since it is off until I do. Then prove it in the preview: two windows, drag a card in one, and show me the list and the calendar moving in the other without a reload.

   Bookmark the version you are on before you send this. Adding subscriptions is the message most likely to take two or three goes, and coming back to a version you know worked beats untangling a half-changed set of channels, especially since restoring the code will not undo anything the attempts wrote to your database.

5. 05

   Sign-in, the rules, and the live feed tested as a stranger

   Everything your team is working on is now in a database with a live feed on it. This step is where you find out whether the feed is a feature or a hole.

   PromptAdd auth and the access rulesCopy

   Add email-and-password sign-up, login, logout, a persisted session, and a profile row created automatically for each new account. Then turn on row-level security across every table, built for the access shape I picked in step 02. If a project belongs to one person: they read and write their own projects and everything under them, and a task is additionally readable and updatable by whoever it is assigned to, and if that is what we built, say plainly that an assignee will not be able to open the board their task sits on, and offer me the smallest change that fixes it. If a project has members: a membership row grants access, every rule on boards, columns, tasks, comments and time entries checks it through a security definer function rather than repeating a subquery, and only an owner may add or remove members. Either way: explicit with-check clauses on inserts and updates, notifications readable only by the person they are for, and a deliberate answer about the accounts table, because reading only your own row is the safe default and it means an assignee picker shows one name. Then, in the preview with a second account, show me four things: it cannot open my project, cannot see my tasks, cannot see my time entries, and does not receive my rows through the realtime feed.

   That fourth check is the reason the live updates went in before the rules. A subscription is a read, and until the policies exist it will happily deliver rows the ordinary query path would refuse, so the only way to know is to sign in as somebody else and watch what arrives.

6. 06
   Destination

   The task drawer, the dashboard, and one last bookmark

   Subtasks, comments with files, the timer that totals, notifications, and the charts over the top. Then a whole day worked through the preview with two accounts, and a bookmark the moment it passes.

   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, and for those attachments use signed links with an expiry generated for somebody allowed to see the task, rather than making the storage bucket public. 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 screen is doing that arithmetic. Then notifications raised by triggers when a task is assigned or commented on, 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 worked out server-side and scoped to the signed-in account. Then walk me through a working day in the preview using two accounts: create a project, fill a board, drag a card and watch the other window, assign a task 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 with all of it.

   The version that gets through that day is the one to bookmark, before a domain or anything else touches it. It is your last recorded point where the four views, the live feed, the timer and both accounts demonstrably worked together, and it is the version you will want back if a later change goes sideways.

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.

One button, and the app you have been previewing is live.

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.

You bring no key and pick no provider: Lovable manages an API key per project, and if you do not name a model it chooses one from what you describe. Match the model to the job: fast and cheap for anything that runs on every record, stronger only where the reasoning matters. Send every feature above through that one integration.