Home › Rules › Lovable SaaS app
Lovable SaaS app rules: Project Knowledge template + AGENTS.md
A SaaS in Lovable is three things: login, one core feature, and payments. These rules keep Lovable on that path and away from the two classic money bugs.
Stack these rules assume: Lovable + built-in backend (Cloud) + built-in payments (or your own Stripe account). Different stack? Customize it in the generator.
Where these go: Paste into Project settings → Knowledge. Lovable's docs recommend its built-in payments for most projects (it needs a paid Lovable plan); connecting your own Stripe account also works.
Want the full step-by-step kit?
MVP Spec-to-Build Pack ($7): A fill-in 1-page spec, a landing page prompt, a 7-prompt build sequence in the right order, a "did I leak user data?" checklist, and cheap fix-it prompts.
Get the kit for $7 on Gumroad → See what's inside
or get all 5 kits for $25 (save $14) →
One markdown file, instant download. 7-day refund, no questions asked.
Quick start
- Copy the Project Knowledge below.
- In Lovable, open Project settings → Knowledge and paste it.
- Fill in the
[bracketed]lines. Delete any rule that doesn't fit. - Start your next message with: "Follow the project knowledge for this whole session."
Project Knowledge for Lovable (copy this)
Paste it into Project settings → Knowledge. Lovable's limit is 10,000 characters; this version is 2,140. It also works as-is in Bolt's Project Knowledge. It skips the Commands section, since the builder runs the project for you.
# Project rules: Lovable SaaS app
Instructions for AI coding agents working on this project. Replace anything in [brackets].
## Project
- What it is: [one sentence: what you are building and who it is for]
- Stack: Lovable + built-in backend (Cloud) + built-in payments (or your own Stripe account)
- Version 1 only needs to: [the ONE thing it must do]
## Project rules
- Version 1 is: sign up, [do the one core thing], pay. Ask before adding teams, admin panels, or settings pages.
- Use Lovable's built-in authentication. Never store passwords or build our own login system.
- Payments use Lovable's built-in payments or my Stripe account. Prices come from the server or the payment provider, never from the browser.
- Mark a user as paid only after the payment provider confirms it, never just because they reached a success page.
- Gate paid features in the backend (database rules or server checks), not just by hiding buttons.
- Test the whole flow in test mode (sign up → pay → get access) before switching to live payments.
## How to work
- Do one task per request. If my request is really several tasks, list them and do only the first.
- Before writing code, give a 3-line plan: what you'll change, which files, and how I'll test it.
- Make the smallest change that works. Don't refactor, rename, or reformat code I didn't ask about.
- Ask before adding a dependency, deleting or moving files, changing the data/database structure, or touching more than 3 files.
- If you're not sure a library, API, or setting exists in the version we use, say so and check the installed package or the docs instead of guessing.
- Never say something works unless you ran it or I confirmed it. Report errors exactly.
- Secrets (API keys, tokens, passwords) live only in environment variables or a .env file listed in .gitignore. Never print, hardcode, or commit them.
- Never run destructive commands (rm -rf, git reset --hard, force-push, dropping tables) without asking first.
## Finish every task with
1. What changed (list the files).
2. How to run or test it in under a minute, and what I should see.
3. A suggested git commit message.
Building this in a browser app builder? These rules work as Project Knowledge in both. Try Lovable · Try Bolt
Disclosure: the Bolt link is an affiliate (referral) link. If you sign up or buy through it, VibeKits may earn a commission at no extra cost to you. The Lovable link is a plain link. It never changes our pick.
AGENTS.md (if you sync to GitHub or work locally)
Same rules as a file, for when you export the code or keep editing it in Cursor, Codex, Copilot or Claude Code.
# AGENTS.md: Lovable SaaS app
Instructions for AI coding agents working on this project. Replace anything in [brackets].
## Project
- What it is: [one sentence: what you are building and who it is for]
- Stack: Lovable + built-in backend (Cloud) + built-in payments (or your own Stripe account)
- Version 1 only needs to: [the ONE thing it must do]
## Project rules
- Version 1 is: sign up, [do the one core thing], pay. Ask before adding teams, admin panels, or settings pages.
- Use Lovable's built-in authentication. Never store passwords or build our own login system.
- Payments use Lovable's built-in payments or my Stripe account. Prices come from the server or the payment provider, never from the browser.
- Mark a user as paid only after the payment provider confirms it, never just because they reached a success page.
- Gate paid features in the backend (database rules or server checks), not just by hiding buttons.
- Test the whole flow in test mode (sign up → pay → get access) before switching to live payments.
## How to work
- Do one task per request. If my request is really several tasks, list them and do only the first.
- Before writing code, give a 3-line plan: what you'll change, which files, and how I'll test it.
- Make the smallest change that works. Don't refactor, rename, or reformat code I didn't ask about.
- Ask before adding a dependency, deleting or moving files, changing the data/database structure, or touching more than 3 files.
- If you're not sure a library, API, or setting exists in the version we use, say so and check the installed package or the docs instead of guessing.
- Never say something works unless you ran it or I confirmed it. Report errors exactly.
- Secrets (API keys, tokens, passwords) live only in environment variables or a .env file listed in .gitignore. Never print, hardcode, or commit them.
- Never run destructive commands (rm -rf, git reset --hard, force-push, dropping tables) without asking first.
## Finish every task with
1. What changed (list the files).
2. How to run or test it in under a minute, and what I should see.
3. A suggested git commit message.
Want the full step-by-step kit?
MVP Spec-to-Build Pack ($7): A fill-in 1-page spec, a landing page prompt, a 7-prompt build sequence in the right order, a "did I leak user data?" checklist, and cheap fix-it prompts.
Get the kit for $7 on Gumroad → See what's inside
or get all 5 kits for $25 (save $14) →
One markdown file, instant download. 7-day refund, no questions asked.
Why each rule exists
- Lovable SaaS app ruleVersion 1 is: sign up, [do the one core thing], pay. Ask before adding teams, admin panels, or settings pages.Why: SaaS MVPs die from scope creep. Every extra screen is more credits and more bugs before your first customer.
- Lovable SaaS app ruleUse Lovable's built-in authentication. Never store passwords or build our own login system.Why: Hand-rolled login is where serious security bugs live.
- Lovable SaaS app rulePayments use Lovable's built-in payments or my Stripe account. Prices come from the server or the payment provider, never from the browser.Why: If the browser can send the price, someone will send $0.
- Lovable SaaS app ruleMark a user as paid only after the payment provider confirms it, never just because they reached a success page.Why: Anyone can open your success URL. Only the provider's confirmation proves they paid.
- Lovable SaaS app ruleGate paid features in the backend (database rules or server checks), not just by hiding buttons.Why: Hidden buttons stop honest users. Backend checks stop everyone. (Lovable's docs also note subscriptions need logged-in users.)
- Lovable SaaS app ruleTest the whole flow in test mode (sign up → pay → get access) before switching to live payments.Why: Test mode lets you run the full purchase as many times as you like without real money.
- How to workDo one task per request. If my request is really several tasks, list them and do only the first.Why: Big multi-part requests are where AI tools change 12 files and you can't tell which change broke things.
- How to workBefore writing code, give a 3-line plan: what you'll change, which files, and how I'll test it.Why: A plan you can read in 10 seconds catches the wrong approach before it costs you an hour or a pile of credits.
- How to workMake the smallest change that works. Don't refactor, rename, or reformat code I didn't ask about.Why: Drive-by "cleanups" are the #1 cause of "it was working yesterday".
- How to workAsk before adding a dependency, deleting or moving files, changing the data/database structure, or touching more than 3 files.Why: These are the changes that are hard to undo. One quick question is cheaper than a rollback.
- How to workIf you're not sure a library, API, or setting exists in the version we use, say so and check the installed package or the docs instead of guessing.Why: AI tools confidently invent functions and config options. Making it check is the cure.
- How to workNever say something works unless you ran it or I confirmed it. Report errors exactly.Why: "Should work now" isn't a test result. You want facts, not optimism.
- How to workSecrets (API keys, tokens, passwords) live only in environment variables or a .env file listed in .gitignore. Never print, hardcode, or commit them.Why: Leaked keys get found by bots within minutes of a public push. This rule is the cheapest insurance you'll ever buy.
- How to workNever run destructive commands (rm -rf, git reset --hard, force-push, dropping tables) without asking first.Why: One bad command can delete the only copy of your work.
- Finish every task withWhat changed, how to test it, and a commit message.Why: This turns every task into a checkpoint: you test it, you commit it, and you always have a last good version to go back to.
Use it as CLAUDE.md (Claude Code)
Pick one:
- Do nothing. Current Claude Code versions read
AGENTS.mdwhen the project has noCLAUDE.md. Run/memoryin a session to check it loaded. - Import it (best if you want Claude-only extras, or you're on an older Claude Code). Create
CLAUDE.mdnext toAGENTS.md:
@AGENTS.md
## Claude Code
- Use plan mode before any change that touches more than 3 files.
- Claude only? Save the same AGENTS.md text as
CLAUDE.mdinstead. Don't keep two separate copies; they drift apart.
Heads-up: if a project has both files and CLAUDE.md doesn't import AGENTS.md, Claude Code reads only CLAUDE.md by default. More in AGENTS.md vs CLAUDE.md.
Use it as Cursor rules (.cursor/rules/*.mdc)
Cursor reads AGENTS.md too, so the file above already works. If you prefer Cursor's own Project Rules, split it into two .mdc files. The .mdc extension and frontmatter are required; Cursor ignores plain .md files in .cursor/rules.
---
description: Project overview and working rules for Lovable SaaS app
alwaysApply: true
---
# Lovable SaaS app
Instructions for AI coding agents working on this project. Replace anything in [brackets].
## Project
- What it is: [one sentence: what you are building and who it is for]
- Stack: Lovable + built-in backend (Cloud) + built-in payments (or your own Stripe account)
- Version 1 only needs to: [the ONE thing it must do]
## How to work
- Do one task per request. If my request is really several tasks, list them and do only the first.
- Before writing code, give a 3-line plan: what you'll change, which files, and how I'll test it.
- Make the smallest change that works. Don't refactor, rename, or reformat code I didn't ask about.
- Ask before adding a dependency, deleting or moving files, changing the data/database structure, or touching more than 3 files.
- If you're not sure a library, API, or setting exists in the version we use, say so and check the installed package or the docs instead of guessing.
- Never say something works unless you ran it or I confirmed it. Report errors exactly.
- Secrets (API keys, tokens, passwords) live only in environment variables or a .env file listed in .gitignore. Never print, hardcode, or commit them.
- Never run destructive commands (rm -rf, git reset --hard, force-push, dropping tables) without asking first.
## Finish every task with
1. What changed (list the files).
2. How to run or test it in under a minute, and what I should see.
3. A suggested git commit message.
The project rules only attach when a matching file is in the chat (globs with alwaysApply: false). Want them on all the time? Change it to alwaysApply: true.
---
globs: src/**/*.tsx, src/**/*.ts
alwaysApply: false
---
# Project rules: Lovable SaaS app
- Version 1 is: sign up, [do the one core thing], pay. Ask before adding teams, admin panels, or settings pages.
- Use Lovable's built-in authentication. Never store passwords or build our own login system.
- Payments use Lovable's built-in payments or my Stripe account. Prices come from the server or the payment provider, never from the browser.
- Mark a user as paid only after the payment provider confirms it, never just because they reached a success page.
- Gate paid features in the backend (database rules or server checks), not just by hiding buttons.
- Test the whole flow in test mode (sign up → pay → get access) before switching to live payments.
Use either AGENTS.md or these .mdc files, not both, so you don't send the same rules twice. See Cursor rules vs AGENTS.md.
Related
- Best AI tool to build a web app MVP (which tool to use, real prices)
- Lovable vs Bolt vs Replit for beginners (honest picks, real prices)
- AGENTS.md, CLAUDE.md and Cursor rules formats explained
Sources
Checked Oct 19, 2026. These tools change often; if something here no longer matches, tell us at [email protected].