Prompt engineering
Lovable prompt engineering: the anatomy of a prompt that ships
Most Lovable rebuilds come from gaps in the original prompt, not bugs in Lovable itself. This guide is the rubric LovableForge uses to grade Lovable prompts — the eight sections every production prompt should cover, and the boring-but-critical clauses that turn a demo into something you can charge for.
1. Product and user
Open the prompt with one sentence that names the product, the primary user, and the value loop. "A practice-management tool for solo physiotherapists to schedule clients, log session notes, and bill at month-end." Lovable's generations get measurably better when the user is named — generic "users" produce generic UI.
2. Data model
List your tables, their key columns, and their relationships in plain English. Don't write SQL — Lovable will. But name the tables, name the foreign keys, and call out anything unusual (soft delete, multi-tenancy, audit columns).
If you have roles, say so explicitly and require them to live in a separate user_roles table. Storing a role column on profiles is a security antipattern Lovable will follow if you let it.
3. Row Level Security
Make RLS a top-level requirement, not a footnote. Every user-data table must have RLS enabled. Policies must scope to auth.uid() or workspace membership via a SECURITY DEFINER helper function (this avoids recursive policy errors).
Spell out the four operations explicitly: SELECT, INSERT, UPDATE, DELETE. "Enable RLS" without policies blocks all access; "add RLS policies" without operation names produces inconsistent coverage.
4. Auth and account lifecycle
Specify the auth methods (email + password, magic link, OAuth) and the account-lifecycle events. Email verification on or off? Password reset flow? Account deletion? First-login trigger that creates a default workspace? Each one is a separate small feature Lovable handles cleanly if asked and ignores if not.
5. Validation and error handling
Demand server-side validation with Zod for every input. Client-side validation is UX; server-side validation is security. The two are not interchangeable.
Require error states for every async flow: loading, empty, error with retry, and success. "Show a toast on success" is concrete; "handle errors gracefully" produces silent failures.
6. UI states (empty, loading, error)
Lovable's defaults skip empty states and replace them with sample data. That's fine for a demo and catastrophic for a real user (who now thinks the data is theirs). Always ask for an explicit empty state with a primary action: "You don't have any clients yet. Add your first one."
7. SEO and discoverability
Require per-route titles and meta descriptions, canonical URLs, Open Graph and Twitter card tags, JSON-LD (Organization sitewide, Article on content pages), a real sitemap.xml served from an edge function, and an open robots.txt.
Without this, your Lovable app is invisible to Google and uncitable by ChatGPT and Perplexity.
8. Verification
End the prompt with a verification gate: a list of curl commands or checks Lovable should run before declaring the build done. "Curl /sitemap.xml and confirm it returns 200 with at least one <url>. Curl / and confirm the HTML contains a <title> and a <meta name="description">." Verification turns a wish-list into an acceptance test.