Lovable PromptsLovable Prompts
    Updated 4 kits · 26 verification checks

    Free Lovable templates with database security that proves itself

    Lovable's own gallery holds 228 templates you remix into your workspace. The 4 here are build kits: a prompt, a Supabase schema with row-level security, and a verify.sql that runs as the wrong user to prove each policy denies what it should. 30 policies and 26 verification checks in all, counted from the files. Pick the sentence that describes your app and see the mistake its kit prevents.

    By Marco Kohns · Counts parsed from each kit's files at build time

    Pick your kit

    Which sentence describes your app?

    SaaS App

    SaaS Starter

    Multi-tenant workspaces, three roles and a working invite flow, with tenancy enforced in the database.

    Tables
    4
    Policies
    12
    Checks
    6

    The trap: a member promoting themselves to owner

    Letting members update their own membership row also lets them rewrite its role. The kit allows the update only when the caller is an owner or admin of that workspace.

    Open the SaaS Starter kit →

    Illustration: the mistake

    create policy "members update membership"
  on public.workspace_members for update
  to authenticated
  using (user_id = auth.uid());
    1. 1Should return only workspaces you are a member of, never every workspace.
    2. 2Should return zero rows for a workspace you do not belong to. Substitute a workspace id you are NOT a member of.
    3. 3Should FAIL for a member (non-admin). If it succeeds, the write policy is too loose.catches it
    4. 4Should FAIL. Nobody may read another workspace's invites.
    5. 5Should FAIL with 'invite is invalid, expired, or already used'.
    6. 6Confirm RLS is on. Every row must show rowsecurity = true.

    The kit's verify.sql, checks as written in its comments. Run them as an ordinary signed-in user, never as service_role.

    Counted from the files

    What is in each of the 4 kits?

    Each build kit with its table, policy and verification-check counts parsed from schema.sql and verify.sql, and the trap it prevents
    KitTablesPoliciesChecksThe trap it prevents
    SaaS Starter4126a member promoting themselves to owner
    Landing Page with Email Capture117a public form that exposes the whole list
    Internal Admin Dashboard257an aggregate function that leaks the event log
    Lightweight CRM3126a record reassigned to someone else

    Two meanings

    Lovable's gallery is 228 finished apps to remix, read 23 October 2026. A kit here is the instruction and the database rules, for an app you build yourself.

    A remix carries

    • Code
    • Database structure (tables and schema, not the records in them)
    • Project chat history, if the copier has edit access and switches it on
    • Custom knowledge, if the project has any

    A remix leaves behind

    • Database records
    • The live URL
    • Collaborators
    • Secrets
    • App users

    Lovable templates ask you to confirm a security acknowledgment before remixing; the button reads Acknowledge and remix.

    Lovable docs: Remix and lovable.dev/templates, both read 23 October 2026.

    Lovable's Security view on the Cadence project: Deep security scan and Quick security scan cards, a No issues found panel, and the chat beside it reporting the scan found nothing at any severity
    Lovable's scans on my SaaS project, 26 September 2026: no issues found. A clean scan says the rules are switched on; the kit's verify.sql shows what they deny.

    Before you run a kit

    In what order do you set up a kit?

    Schema first, verification second, prompt last. Each kit's own steps, as they ship with it.

    SaaS Starter

    1. Run schema.sql in the Supabase SQL editor. Before prompting Lovable. The prompt references these table names, so building first means rework.
    2. Run verify.sql as an ordinary signed-in user. Not as service_role, which bypasses every policy and will make a broken schema look correct.
    3. Paste prompt.md into Lovable. Unedited on the first pass, so you can see what the structure produces before changing it.
    4. Replace the audience line. The Context section names a small team adopting a tool. Changing that one line changes which features Lovable prioritises more than anything else in the prompt.

    Landing Page with Email Capture

    1. Run schema.sql in the Supabase SQL editor. The prompt writes through capture_lead(), which this file creates.
    2. Run verify.sql from the browser client as an anonymous visitor. Query 2 is the one that matters. If a bare select on leads returns rows, stop and fix it before shipping.
    3. Paste prompt.md into Lovable. Then replace the offer and the audience.
    4. Read your list from the dashboard or a server function. Never from the browser. There is no read policy, deliberately.

    Internal Admin Dashboard

    1. Run schema.sql in the Supabase SQL editor. Creates the role type, both tables and the policies.
    2. Grant yourself admin from the SQL editor. The commented statement at the end of schema.sql. Deliberately not an endpoint, because a self-service role grant is a privilege escalation.
    3. Run verify.sql as a member first. The member results prove the policies. Running only as an admin proves nothing.
    4. Paste prompt.md into Lovable.

    Lightweight CRM

    1. Decide shared or private before running schema.sql. This schema is a shared team CRM: every authenticated user reads every record. For per-user isolation, change the select policies to owner_id = auth.uid() first.
    2. Run schema.sql in the Supabase SQL editor.
    3. Run verify.sql as two different users. Queries 3 and 4 only mean anything when run by someone who does not own the record.
    4. Paste prompt.md into Lovable.

    All 4 kits' SQL, every prompt, every Pro version

    The Complete Lovable Bundle: the schema.sql and verify.sql for every kit, unlimited generation and every future drop. One payment. No subscription, no renewal, ever.

    Frequently asked

    What is a Lovable template?

    On Lovable's site, an app from the community gallery that you remix into your own workspace; the gallery showed 228 on 23 October 2026. Here, a build kit: a prompt for Lovable, a Supabase schema with row-level security, and verification queries. The first gives you an app to edit; the second gives Lovable an instruction and a database that is safe to point it at.

    Are these Lovable templates free?

    The kit pages, their prompts and the patterns on this page are free to read and copy without an account. The full schema.sql and verify.sql files for all four kits come with the bundle.

    What does remixing a Lovable template copy?

    Per Lovable's remix docs read 23 October 2026: the code, the database structure without its records, and optionally the chat history and custom knowledge. It leaves the live URL, collaborators, secrets and app users behind, and gallery templates ask for a security acknowledgment before the remix.

    Why do the kits ship verification queries?

    A policy that exists is not proof that it denies. Lovable's scans check that row-level security is switched on and flag common gaps; a query run as the wrong user is what shows a member cannot promote themselves or read another team's rows.

    Which Lovable template should I start with?

    Match the trap your app has: teams and invites (SaaS Starter), a public form (Landing Page), admin-only metrics and an audit log (Admin Dashboard), shared records with one owner each (CRM). The picker at the top does the matching.

    Do these templates work outside Supabase?

    The SQL assumes Supabase, which grants the anon and authenticated roles access to new public tables by default and lets row-level security restrict them. On plain Postgres those grants do not exist, so the policies appear to work while the missing privileges are what blocks access.

    What we did not publish

    • A credit cost per kit. The SQL was validated against Postgres 17; no kit was built end to end in Lovable for this page.
    • A review of the 228 gallery templates. Their security is theirs to state.
    • The mistakes in the picker are illustrations written for this page; the kit SQL beside them is quoted from the files.

    These templates are provided free and as-is, with no warranty of any kind. The SQL is intended to be run against your own Supabase project and will create and alter tables. Read it, run it on a development project first, and review every policy against your own requirements before going near production data. You remain responsible for the security and correctness of anything you ship.

    Sources

    1. The kits' own schema.sql and verify.sql, parsed at build time
    2. lovable.dev/templates, read in a browser 23 October 2026
    3. Lovable docs: Remix, read 23 October 2026
    4. Lovable docs: Security view

    Written by

    Marco Kohns

    Marco Kohns

    Founder of ProtoBites - Venture Growth Studio

    Growth PM at a Silicon Valley scale-up (a16z and General Catalyst backed), ex-Techstars where he consulted 13 early-stage startups, Reforge-trained. Every prompt on this site comes out of shipping ProtoBites' own portfolio products.

    WebsiteLinkedInX