You built the interface in Lovable and the data lives in Supabase.
Unlock the rest of the checks
Two checks in each section are open, including why they matter, how to check them, and the prompt. Every other check keeps its title on the page. The reason, the steps and the prompt for those checks are omitted until you pay. One payment of £10 opens every stack. Access does not expire.
Or pay £15 once for the same access and the AI-Ready Pack. That price is the checklist price plus the pack price. The pack does not change your ranking.
Card details go to Stripe, not to this form. After payment, this browser gets a cookie. Restore access sends a one-hour link if you need another device. Error fixes stay free.
0 of 22 done
Ticks are saved in this browser only.
Security
Critical
Lovable often creates Supabase tables that the browser can reach with the anon key. If row level security is off, anyone who can see that key can read or change every row. Generated projects have shipped with open tables, so this is the first check.
You are working in this repository. Do not add features. Make the smallest change that closes open database access.
Goal: every table in the public schema that the app uses must have row level security enabled, plus policies so a signed-in user can read and write only their own rows.
Steps:
1. Find the Supabase client and list every table the app reads or writes.
2. Add a SQL migration that runs ALTER TABLE ... ENABLE ROW LEVEL SECURITY on each of those tables.
3. Add SELECT, INSERT, UPDATE and DELETE policies. Use auth.uid() matched to the owner column (often user_id). If a table has no owner column, stop and tell me which table, rather than writing a policy that allows everyone.
4. Do not use the service role key in browser code. Do not print any keys.
5. Tell me the SQL you added and how I can confirm it in the Supabase SQL editor.
Critical
The service role key bypasses row level security. If it is bundled into the Lovable app, anyone can extract it from the browser and read the database. The anon key is the only Supabase key that belongs in frontend code.
You are working in this repository. Do not add features.
Goal: the Supabase service role key must never be shipped to the browser. The browser client must use the anon key only.
Steps:
1. Search the repo for service_role, SERVICE_ROLE, and any key that is not the anon key.
2. If server-side code genuinely needs the service role key, read it from an environment variable that is not prefixed for the client (no VITE_ prefix).
3. Remove the service role key from every file that is imported by the UI.
4. If you find the real key in the repo, replace it with an environment variable and tell me to rotate the key in Supabase. Do not print the key.
5. Summarise the files you changed.
High
The reason, the checks and the prompt for this item are paid.
If the browser tells Stripe how much to charge, a visitor can change that number. Lovable apps often put the price in the checkout request. The server, or a Supabase Edge Function, should look up the price and create the Stripe session.
You are working in this repository. Do not add features.
Goal: the amount a customer pays must be decided on the server. The browser must not choose the price.
Steps:
1. Find the checkout code. If it runs in the browser and sends an amount, move session creation to a server function or Supabase Edge Function.
2. The server should load the price id or amount from trusted data, then create the Checkout Session with the Stripe secret key.
3. The secret key must come from an environment variable that is not exposed to the client.
4. Verify the webhook signature before you mark an order as paid. See Stripe's constructEvent pattern.
5. Do not print the secret key. Tell me what to put in Stripe test mode to try one payment.
Deploy
High
A Lovable preview URL is fine for building. It is a poor place to send customers: the address can change, and it does not look like your product. Sign-in redirects and cookies also need a stable https origin.
You are working in this repository. Do not add features.
Goal: the app should assume it is served from a single production origin over HTTPS.
Steps:
1. Find every hard-coded preview URL, localhost URL, or http:// URL used for redirects, canonical links or API calls.
2. Replace them with a site URL from an environment variable, and document the name of that variable.
3. Make sure auth redirects and any cookie settings use that origin.
4. Do not change the visual design.
5. List the DNS record I still need to add at the host. Do not invent a registrar login.
SEO and AI visibility
The AI-Ready Pack is a paid download of llms.txt templates, robots rules, schema and a short guide. Publishing those files does not, by itself, change your ranking.
Medium
Search results and chat apps quote your title and meta description. A default Lovable title tells nobody what the product does. Each public page needs its own title and a short description.
You are working in this repository. Do not add features.
Goal: every public page has a unique title and meta description that describe this product. Also add an Open Graph title, description and image if the framework already supports them.
Steps:
1. Find the layout or head component.
2. Set a specific title and description for the home page and each public route. Do not leave the generator's default title.
3. Do not invent reviews, user counts or awards.
4. Tell me the title and description you used so I can edit the wording.
A SoftwareApplication block in JSON-LD gives search engines the product name, URL and description in a structured form. It does not replace a clear page. The type is published by schema.org.
You are working in this repository. Do not add features.
Goal: The public homepage includes valid SoftwareApplication JSON-LD.
Work in the Lovable project, in the shared head or the public files the published site actually serves.
Steps:
1. Add one application/ld+json script with @context https://schema.org and @type SoftwareApplication.
2. Set name, url and description from the real product. Do not add aggregateRating, review, or offers unless I have given you those facts.
3. Keep the JSON valid.
4. Do not invent traffic numbers, reviews, or testimonials.
5. Show me the files you changed.
If the app stores accounts, payments or a newsletter, people in the UK and EU need to know what you collect and how to contact you. A missing privacy page is also a trust problem on the first day you share the link.
You are working in this repository. Do not add features.
Goal: add a privacy page that matches what this app actually stores, and link it from the footer.
Steps:
1. List the personal data the app collects by reading the forms, auth code and database tables. Do not guess extra analytics.
2. Add a /privacy page in plain language. Include what is collected, why, how long you keep it, and a contact email placeholder I can replace: [CONTACT EMAIL].
3. Link it from the site footer.
4. Do not copy a random policy from the web. Do not claim a company address you cannot see in the project.
5. Tell me what I must fill in before launch.
Monitoring
Medium
The Lovable preview hides a lot of failures. Once real people use the app, a blank screen and an unread browser console are how you lose the first users. You need one place that records server and client errors.
You are working in this repository. Do not add features.
Goal: unhandled errors in production should be logged where I can read them, without recording secrets.
Steps:
1. Find the app's error boundary or the lack of one.
2. Log a short message and a request id. Strip emails from query strings if they appear, and never log Authorization headers or Stripe secrets.
3. If there is no tracker configured, write errors with console.error as structured JSON so the host can collect them.
4. Show the user a plain message when something fails, rather than a blank page.
5. Tell me where to look after I deploy.