Verified against Lovable · 2026-07-31
Add a feature to a live Lovable app without breaking existing data or access rules
A Lovable brief for extending a live app already holding real user data, structured around additive-only schema changes and a written before/after for any row-level-security policy the new feature touches.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You are adding a feature to Clientflow, an existing Lovable app already in use by real users with real data — this is a migration, not a fresh build, and existing rows, existing RLS policies, and existing user sessions must all keep working through the change. CURRENT STATE Existing tables and their relevant columns: clients(id, owner_id, name, email), projects(id, client_id, owner_id, title, status) Existing row-level security policies I know about: both tables filter strictly on owner_id = auth.uid() — single-user ownership only, no sharing between users today Current live user count / data volume, roughly: 340 signed-up users, roughly 2,900 client rows total NEW FEATURE Let an owner invite a second teammate to view (not edit) their clients and projects — a lightweight read-only collaborator role, not full multi-user ownership MIGRATION RULES Treat this as an additive change wherever possible — new tables and new nullable columns on existing tables — rather than renaming or dropping anything that existing code or existing RLS policies reference; a rename that isn't caught everywhere it's used breaks in production, not in preview. If a column genuinely must change type or meaning, write the migration as widen-then-backfill-then-narrow across separate steps, not a single destructive ALTER that could fail partway through and leave the table in a broken intermediate state. Any new table this feature introduces needs its own explicit row-level security policy from the moment it's created — do not let the feature go live with a business table that has RLS disabled, even temporarily "just for testing," since a table with RLS disabled on a production Supabase project is fully public to anyone who can reach the API. If the new feature changes what an existing RLS policy should allow — for example, a feature that introduces shared access to something that used to be strictly private to one user — write out the exact before-and-after policy logic in plain language before touching the policy itself, so the change in who can see what is a deliberate, reviewed decision, not a side effect of adding an unrelated feature. ROLLOUT AND SAFETY Assume real users are on this app right now — do not delete or truncate any existing table as part of building this feature, even a table you believe is now unused; leave it in place and tell me it looks unused so I can decide separately. If the feature needs a one-time backfill of existing rows (setting a new column's initial value based on old data), describe the backfill as its own explicit step with what it does to existing rows, and confirm it's safe to run more than once without duplicating or corrupting data, in case it needs to be re-run. WHAT TO BUILD An "Invite a viewer" button on the settings page that sends an invite by email, and a banner on the dashboard for an accepted viewer showing whose data they are viewing OUTPUT Before writing any code, list: every schema change, in the order you'd apply them; every RLS policy that's new or modified, with the plain-language before/after; and anything from the current state above that this feature touches indirectly and might affect in a way I haven't asked about. Wait for me to confirm that list before generating the actual screens and queries.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
A chat-based app builder generating the whole affected slice of an app fresh from a conversation has a natural instinct to regenerate a table definition wholesale to fit a new feature cleanly — that instinct reads great in the builder's own preview, where tables are empty or lightly seeded, and is destructive the moment it runs against a table with real rows in it. Explicitly demanding additive, nullable-first changes, and a widen-then-backfill-then-narrow path for anything that genuinely can't stay additive, closes that gap by naming the specific migration shape the model should reach for instead of the wholesale-regeneration shape it defaults to. Requiring a written before/after for any RLS policy that changes what's shared targets the single highest-consequence class of bug in exactly this kind of change. An ownership model moving from single-user to shared is precisely the change most likely to accidentally over-broaden a policy — a rewritten policy meant to add one specific collaborator that ends up loose enough to let any authenticated user in, because "any authenticated user" and "this one accepted collaborator" can look like the same SQL predicate if the join condition isn't written carefully. Writing the intended behavior in plain language before touching SQL creates something a human can actually verify against, instead of trusting a generated policy is correct because it looks plausible. The "wait for confirmation before generating code" instruction matters specifically because a Lovable chat session that goes straight from a feature request to full implementation gives you nothing to review before the change is already live in the connected Supabase project — there's no separate staging step by default. Forcing a plan-then-pause turns a one-shot, already-applied generation into something with an actual review gate, which is the entire difference between an experiment run against a copy of the data and a production change made directly against real users' rows.
Verified against
Lovable Lovable web app (Supabase-integrated chat builder) · 2026-07-31
Changelog
- 2026-07-31 — Initial publish, verified against Lovable with an additive-only migration path and a mandatory plan-before-code review gate.
Need this built into your business?
If a prompt isn't enough — custom software, built and maintained for you — that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
