BoilerPrompt
Lovable

Lovable prompt to build a to-do app

A to-do list is the fastest way to learn how Lovable wires auth, row level security, and optimistic UI together in one small app. This prompt specifies the tasks and lists tables, the filters, and the rollback behavior up front, so you end up with a per-user task manager instead of a static checkbox demo.

Last updated

Prompt
Build a to-do app with Supabase auth so each user only sees their own tasks.

Screens: a login and signup screen, a main list view, and a settings page for display preferences.

Data model: a tasks table with title, notes, due_date, priority, completed_at, sort_order, and user_id, with row level security so users only read and write their own rows. Add a lists table so tasks can be grouped, with a default Inbox list created on signup.

Behaviors: inline task creation from a single input at the top of the list, optimistic checkbox toggling that writes completed_at, drag to reorder within a list persisted to sort_order, and a filter bar for Today, Upcoming, and Completed. Overdue tasks show the due date in red.

Empty and error states: a first-run state offering three sample tasks, a friendly message when a filter returns nothing, and a retry banner if a write fails so the checkbox rolls back visibly.

Styling: clean single-column layout with a max width around 640px, shadcn components, a subtle strike-through animation on completion, and a dark mode toggle stored per user.

Acceptance: signing up creates the Inbox list automatically, a task checked off leaves the Today filter after refresh, reordering survives a reload, and a second account cannot see the first account's tasks from the UI or the browser console.

Same task in other tools

Questions about this prompt

Will Lovable set up row level security for the tasks table on its own?

It usually enables RLS when the prompt mentions per-user data, but verify in the Supabase panel that policies exist for select, insert, update, and delete. The acceptance line about a second account exists to force that check.

How do I adapt this into a team to-do app?

Add a workspaces table and a membership join table, then change the policies to check membership instead of ownership. Ask for that as a follow-up prompt, Lovable handles incremental schema changes well.

Drag-to-reorder stopped persisting after later edits. What happened?

A regenerated list component often drops the sort_order write while keeping the drag animation. Tell Lovable the reorder must update sort_order in Supabase and add it back to your acceptance list so the regression surfaces.

Related prompts