Lovable Starts With A Product Brief

Lovable works best when you describe the app like a product manager: user, job, screens, data, and constraints.

1. 1Name the job before naming the tool.
2. 2Write the smallest useful scope the agent can finish.
3. 3Run the result as a user, not as a fan of the tool.
4. 4Inspect the diff, data access, and failure path before sharing.

Build a client portal for a cleaning business. Screens: login, job list, job detail, invoice status. Data: clients, jobs, invoices. Constraint: users only see their own client account.

• What should the user be able to do when this is finished?
• What data should the app or agent never expose?
• What test proves the change works?
• What rollback path exists if the output is wrong?

A Lovable app with Supabase needs RLS policies that match real ownership rules, not just tables that happen to exist.

1. 1Name the job before naming the tool.
2. 2Write the smallest useful scope the agent can finish.
3. 3Run the result as a user, not as a fan of the tool.
4. 4Inspect the diff, data access, and failure path before sharing.

Audit every table. For each one, write: who owns this row, who can read it, who can insert it, who can update it, who can delete it. Then implement policies.

• What should the user be able to do when this is finished?
• What data should the app or agent never expose?
• What test proves the change works?
• What rollback path exists if the output is wrong?

Repeated 'try to fix' prompts can make an app worse. Freeze the bug, capture evidence, and ask for one surgical repair.

1. 1Name the job before naming the tool.
2. 2Write the smallest useful scope the agent can finish.
3. 3Run the result as a user, not as a fan of the tool.
4. 4Inspect the diff, data access, and failure path before sharing.

Do not regenerate the whole page. Fix only the save button freeze. Here are the console and network errors. Explain the root cause before editing.

• What should the user be able to do when this is finished?
• What data should the app or agent never expose?
• What test proves the change works?
• What rollback path exists if the output is wrong?

Login, role assignment, route guards, and database policies must agree. If one layer disagrees, the app leaks capability.

1. 1Name the job before naming the tool.
2. 2Write the smallest useful scope the agent can finish.
3. 3Run the result as a user, not as a fan of the tool.
4. 4Inspect the diff, data access, and failure path before sharing.

Create roles: owner, manager, viewer. Add route guards and Supabase policies for each. Show me a table mapping role to every route and table action.

• What should the user be able to do when this is finished?
• What data should the app or agent never expose?
• What test proves the change works?
• What rollback path exists if the output is wrong?

Lovable can get you started, but ownership means knowing where the code, database, secrets, and deploy live.

1. 1Name the job before naming the tool.
2. 2Write the smallest useful scope the agent can finish.
3. 3Run the result as a user, not as a fan of the tool.
4. 4Inspect the diff, data access, and failure path before sharing.

Create HANDOFF.md for this Lovable app: repo URL, deploy URL, Supabase project, env vars, auth providers, tables, policies, and rollback steps.

• What should the user be able to do when this is finished?
• What data should the app or agent never expose?
• What test proves the change works?
• What rollback path exists if the output is wrong?