Free Lovable Templates

Four build kits, free and without a sign-up. Each one is a complete build prompt plus the Supabase schema it expects, with row-level security already written and queries that prove the policies deny what they should.

The schema half is the point. Lovable generates the interface well and generates access control badly enough that insufficient row-level security in Lovable projects has its own CVE. A prompt alone will not fix that, so these ship the policies too.

What a template is here, precisely

A build prompt, a schema with policies, and verification queries. Three files you can read before you run anything.

It is not a repository you clone and run, and not a theme. Lovable generates the app from the prompt; the SQL gives it a database that is safe to point at. We are explicit about that because the alternative is a page that promises a zip and delivers a prompt list.

SaaS App

3 files

SaaS Starter

Multi-tenant workspaces, three roles, and a working invite flow, with the row-level security that makes tenancy real rather than cosmetic.

Landing Page

3 files

Landing Page with Email Capture

One offer, one action, a real indexable copy body, and the insert-only policy that stops your email list being publicly downloadable.

Backend Logic

3 files

Internal Admin Dashboard

Role-gated metrics and an append-only event log, where the admin check lives in the database rather than in a hidden menu item.

App Builder

3 files

Lightweight CRM

Companies, contacts and an append-only note timeline for a founder doing their own sales, with shared team reads and owner-only writes.

Before you run the SQL

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.

These schemas assume Supabase, which grants the anon and authenticated roles access to new tables in the public schema by default. Row-level security is what then restricts those roles. If you run this SQL on a plain Postgres instance instead, those grants do not exist, so the policies will appear to work while actually being enforced by missing privileges rather than by the policies themselves.

Templates or prompts?

Use a template when you are starting something and want the database decided for you, including who can read what. Use a prompt when you know the shape of what you are building and only need the instruction.

The prompt library has 101 prompts across six categories, each tied to a growth channel. The generator writes one for an idea that does not match an existing pattern.

Why row-level security is the hard part

Every one of these kits ships policies that deny by default, and verification queries you run as an ordinary user rather than as the service role. That distinction matters more than anything else here: the service role bypasses every policy, so testing with it makes a broken schema look correct.

The specific traps the four kits handle are a recursive policy on a membership table, a public form that must accept writes without exposing reads, an aggregate function that quietly leaks a whole event log if it is made security definer, and an update policy missing its with check clause so a record can be reassigned. Each is called out on the relevant page.