Lovable plus Firebase plus Stripe launch checklist

Confirm the production URL

Preview and production can return different routes, headers, and environment values.

Fix prompt

Plain http requests to this app do not redirect to https. Make every request on http answer with a 301 to the same path on https. On Lovable hosting this is usually automatic once a custom domain is verified, so first check the domain setup in Project settings, Domains, and confirm the domain shows as verified. If the app has its own server entry, add the redirect there for requests whose forwarded protocol is http. Change nothing else and tell me what you found so I can re-run the check.

Run the primary journey from a clean session

A working first screen does not prove the main task completes.

Fix prompt

In Lovable chat: Run the main user journey from a clean browser. Record each request, state change, failure path, and final result. Then show me the files changed and the checks run.

Enforce authorization on the server

Hidden buttons do not stop a direct request to a protected action.

Fix prompt

In Lovable chat: List every protected read and write. Enforce identity and ownership on the server for each one, then test a second account against them. Then show me the files changed and the checks run.

Validate every server input

Browser validation can be skipped by direct requests.

Fix prompt

In Lovable chat: Add strict server-side validation and length limits to every public or authenticated mutation. Return clear errors without internal details. Then show me the files changed and the checks run.

Keep private keys out of browser code

Anyone who opens the page can read this key and use it directly against the service it belongs to, with your account paying for it.

Fix prompt

A server-side secret is compiled into the browser bundle: a {pattern} in {bundle}. Do three things in this order. First, tell me which provider it belongs to so I can rotate it now; a key in a bundle counts as leaked. Second, move every call that uses that key into a backend function and read the key from a secret there, never from a VITE_ or public variable. Third, remove the key from the frontend code and from any environment variable that ships to the browser. Do not print the key in chat. Change nothing else and list the files you touched.

Test the main failure path

Timeouts and rejected requests need a truthful, recoverable interface.

Fix prompt

In Lovable chat: Force the main external request to time out and fail. Show a truthful error, preserve user input, and provide a retry that cannot duplicate work. Then show me the files changed and the checks run.

Rollback and recovery

Whether you can put the previous version back, and how long that takes.

A URL cannot verify this. A Launch Review can.

Fix prompt

Deploy a trivial change, then roll it back, and time how long the app is wrong for.

Error monitoring

Whether a failure in production reaches a human rather than sitting in a log nobody opens.

A URL cannot verify this. A Launch Review can.

Fix prompt

Trigger a deliberate error in production and see whether anything alerts you within five minutes.

Rate limiting and abuse controls

Whether a script can hammer your forms, sign up loop, or paid endpoints without being slowed down.

A URL cannot verify this. A Launch Review can.

Fix prompt

Send the same form fifty times in a minute from one address and see whether anything stops you.

Make Stripe webhooks idempotent

Stripe can deliver the same event more than once.

Fix prompt

In Lovable chat: Verify Stripe webhook signatures, store processed event IDs, and make repeated delivery leave access and records unchanged. Then show me the files changed and the checks run.

Separate Stripe test and live keys

Mixed modes can create records without granting the matching production access.

Fix prompt

In Lovable chat: Keep Stripe test and live keys in separate deployment environments. Confirm the production checkout, webhook, and price IDs all use live mode. Then show me the files changed and the checks run.

Test every payment outcome

Whether payment events are verified, replay safe, and matched to the right customer record.

A URL cannot verify this. A Launch Review can.

Fix prompt

Replay a payment webhook twice and confirm the customer is only granted access once.

Test Firebase rules with two accounts

Client SDK checks do not replace deployed Firestore or Storage rules.

Fix prompt

In Lovable chat: Use the rules emulator or a test project to verify anonymous, owner, other-user, and administrator reads and writes for every collection and storage path. Then show me the files changed and the checks run.

Sign in and account flows

Whether sign in, password or code reset, and session expiry behave under real use.

A URL cannot verify this. A Launch Review can.

Fix prompt

Sign in as two different accounts in two browsers and try to open the other account's pages by address.

Test personal-data deletion

Whether stored personal details are limited, deletable on request, and out of your logs.

A URL cannot verify this. A Launch Review can.

Fix prompt

Search your logs for an email address you know is in the database and see whether it appears.

Keep personal data out of logs

Email addresses and other personal details can spread into long-lived logging systems.

Fix prompt

In Lovable chat: Trigger each customer-data flow, search the resulting logs for known personal values, then redact fields at the logging boundary and repeat the test. Then show me the files changed and the checks run.

No privacy page is linked

Payment providers, app stores, and several privacy laws expect a reachable privacy page before you take anyone's details.

Fix prompt

Create a real privacy policy page at /privacy and link it from the footer on every page. It must cover what data the app collects, why, how long it is kept, who it is shared with, and how to request deletion, written for this specific app with no placeholder text and no lorem ipsum. Use the existing layout and typography so it matches the site. Do not change any other page, route, or table. When done, give me the link so I can read it and re-run the check. If this app takes payments, Stripe's readiness review reads this page, so it has to be complete.

No terms page is linked

Without stated terms you have no written basis for suspending misuse or limiting your liability.

Fix prompt

Create a real terms of service page at /terms and link it from the footer on every page. It must cover what the service is, acceptable use, payment and cancellation terms, limitation of liability, and governing law, written for this specific app with no placeholder text and no lorem ipsum. Use the existing layout and typography so it matches the site. Do not change any other page, route, or table. When done, give me the link so I can read it and re-run the check. If this app takes payments, Stripe's readiness review reads this page, so it has to be complete.

Review browser response headers

Explicit browser policies reduce avoidable exposure and make deployment behavior easier to inspect.

Fix prompt

This app sends no Content-Security-Policy header. Add one on every HTML response from the server entry. Start with default-src 'self', object-src 'none', base-uri 'self', and frame-ancestors 'none' unless the app must be embedded. Then add only the origins the app actually uses: the script and frame origins for the payment provider if there is one, the connect origin for the backend, and any font or image hosts. Because this framework injects inline scripts for hydration, use its nonce support for script-src rather than unsafe-inline. Roll it out as Content-Security-Policy-Report-Only first, load every page including a checkout if the app has one, fix each console violation, and only then switch the header to enforcing. If the project is on the older Vite stack, run the Migrate to TanStack Start action first, because static apps cannot set headers. Change nothing else and paste the final policy back to me.

Source maps are published next to the app code

Anyone can rebuild your original files, including comments, file names, and any logic you assumed was hidden.

Fix prompt

A production source map is publicly reachable at {map_url} for {bundle}, which hands anyone your readable source. Turn off source map generation for production builds in the build configuration and make sure no .map files are published. Keep source maps for the preview environment if you want them. Change nothing else, rebuild, and tell me when the .map address returns 404 so I can re-run the check.

Check missing and private routes

Fallback routing can return app content where a clear missing or denied response belongs.

Fix prompt

In Lovable chat: Request a missing page and each common private path in production. Return the intended missing or denied response without internal details. Then show me the files changed and the checks run.

Remove sensitive values from logs

Production logs often outlive the request that created them and may be visible to more people.

Fix prompt

In Lovable chat: Review production logging. Remove tokens, authorization headers, full request bodies, personal details, and internal error stacks from user-facing responses. Then show me the files changed and the checks run.

Review production dependencies

Unused and outdated packages increase maintenance work and can change deployment behavior.

Fix prompt

In Lovable chat: List production dependencies, remove unused packages, review reported issues, and run the existing test and build commands after each change. Then show me the files changed and the checks run.

Test session expiry

Expired sessions must stop protected work and return people to a recoverable sign-in state.

Fix prompt

In Lovable chat: Expire a session during a protected read and write. Confirm access stops, unsaved input is preserved where possible, and sign-in returns to the intended page. Then show me the files changed and the checks run.

Define personal-data retention

Keeping personal data without a time limit increases operational and privacy obligations.

Fix prompt

In Lovable chat: List each personal field, why it is collected, its retention period, and the deletion job or manual process that enforces that period. Then show me the files changed and the checks run.

Review caching boundaries

Private or personalized responses must not be reused for another visitor.

Fix prompt

In Lovable chat: Inspect caching for HTML, API responses, and service workers. Exclude authenticated, payment, and personal-data routes from shared caches. Then show me the files changed and the checks run.

Review the Lovable release boundary

Generated and agent-edited code still needs an explicit production review.

Fix prompt

In Lovable chat: Review the production build, server and browser boundary, environment values, and generated routes. Record every observed difference from preview. Then show me the files changed and the checks run.

Review Lovable changes before publishing

A focused diff review catches unrelated generated changes before they reach production.

Fix prompt

In Lovable chat: Review the full release diff. Remove unrelated changes, confirm each changed file has an owner, and run the checks affected by that diff. Then show me the files changed and the checks run.

Record Lovable release evidence

A dated record makes regressions and rollback decisions easier to explain.

Fix prompt

In Lovable chat: Record the release commit, production URL, test time, owner, observed result, and rollback reference for this launch. Then show me the files changed and the checks run.

Confirm the Lovable published version

The preview can be newer than the public version.

Fix prompt

In Lovable chat: Publish the intended version, open the public URL in a clean browser, and compare its release behavior with the preview. Then show me the files changed and the checks run.