The Lovable Deployment Checklist Before You Send a URL to Paying Customers

Why the "Publish" Button Is the Start, Not the End

Lovable ships a green Publish button, a generated subdomain, and a shareable URL. That URL is fine for showing a friend. It is not fine for charging someone money.

The gap between a working prototype and a live product that can survive a weekend of real traffic is wider than most vibe coders realize. The prototype runs on default settings. Defaults are generous for demos and hostile for production. Rate limits are set for no one abusing the endpoint because no one is using the endpoint. Row Level Security is off on tables you forgot you created. The email that confirms a user's account lands in spam because your DKIM record has a typo or was never set at all. The Supabase egress meter is quietly ticking toward a bill you did not budget for.

What follows is the pre-launch checklist WitsCode runs before any Lovable app we touch gets handed to a paying customer. Fifteen items, grouped into four areas: domain and email delivery, authentication and data safety, observability and cost control, and compliance and analytics. Treat this as the list you run top to bottom the day before go-live. If anything is red, the URL does not ship.

Custom Domain, Certificates, and Getting Email Into the Inbox

The first four items are about the envelope: the URL customers type and the email addresses your product sends from. Lovable apps default to a yourapp.lovable.app subdomain, which is fine for staging and catastrophic for conversion. A customer who has just paid you forty dollars a month expects to see your domain in the address bar, not someone else's. Point your apex or www subdomain at the Lovable app via the DNS records Lovable provides, then wait for the TLS certificate to provision and, more importantly, verify that auto-renewal is working. Lovable and Vercel both handle renewal automatically, but renewal only works if the DNS validation record stays in place. I have seen teams remove the validation CNAME after initial provisioning, thinking it was scaffolding, and discover ninety days later that their certificate expired overnight.

Email deliverability is the single area where Lovable apps fail most often. If you are using Resend, which is the default integration for transactional email in most Lovable templates, you need three DNS records working together. The first is an SPF record on your root domain: v=spf1 include:_spf.resend.com ~all. If you already have an SPF record for Google Workspace, merge the includes into one record rather than creating a second, because RFC 7208 forbids multiple SPF records on the same domain. The second is the DKIM CNAME Resend generates when you add a domain, typically resend._domainkey pointing at a Resend-hosted target. The third is the record almost everyone forgets: the Return-Path CNAME, usually at a send subdomain, pointing at feedback-smtp.us-east-1.amazonses.com. Without that Return-Path record, SPF passes at the protocol level but fails SPF alignment under DMARC, and Gmail responds by showing your recipients "via resend.dev" next to your sender name. That small piece of text shaves conversion on every welcome email.

Finally, publish a DMARC record at _dmarc.yourdomain. The minimum viable policy is p=quarantine with a rua= address pointing at a mailbox you actually read, because DMARC reports will tell you within a week if a forgotten marketing tool is sending from your domain and failing alignment. Start at p=quarantine; once aggregate reports are clean for thirty days, tighten to p=reject. Do not deploy to production on p=none, because that policy tells receiving mail servers to do nothing about failures, which is the opposite of what a production mail setup needs.

Row Level Security, Rate Limits, and Keeping Secrets Out of the Bundle

The second group is where real money and real data live. Items five through eight are about stopping strangers from reading your database and stopping bots from hammering your auth endpoints.

Row Level Security is the Postgres feature that makes Supabase safe to expose directly to browsers. Lovable generates tables with RLS disabled by default when you prompt for a new schema, because the AI wants your queries to just work in the preview. This is the single most dangerous default in the entire stack. Before launch, run a query against pg_tables filtered to your public schema and confirm every row has rowsecurity = true, then open each table in the Supabase dashboard and confirm that at least one policy exists for every operation you actually use. A table with RLS enabled and no policies is locked down; a table with RLS disabled and a policy defined is wide open, because the disabled flag wins. Audit both.

Supabase rate limits are the second trap. The platform defaults are set for demos, not for products, and they get dangerous in both directions. The /token endpoint, which handles sign-in and token refresh, defaults to thirty requests per five minutes per IP. That is permissive enough to let a credential-stuffing bot try six attempts per minute indefinitely. Dial it to five per five minutes for a product with normal sign-in patterns. The /otp and /recover endpoints default to thirty per hour, which is wildly generous for a password reset flow: an attacker can trigger thirty reset emails to a victim's mailbox every hour for free, which is harassment at best and a phishing setup at worst. Pull /recover to five per hour and /otp to three per hour. At the other end, the anon API rate limits are sometimes too tight for product traffic: if you are serving a feed of posts with one hundred reads per minute per IP as your ceiling, a single tab with live polling can hit the wall. Raise the product-read limits while lowering the auth limits; the two do not need to match.

Item seven is the bundle audit. The Supabase service_role key bypasses RLS entirely and must never ship to a browser. Lovable's code generator is good about using the anon key in client components and the service_role key in Edge Functions, but prompts that say "give me admin access to update any user" sometimes pull service_role into a client-side handler. Before you ship, grep your build output for the string service_role and confirm every match is inside a server-only file. For Next.js, run grep -r "service_role" .next/static and expect zero hits. One hit means you rotate the key before launch and refactor the call into an Edge Function or server action.

Item eight closes the secrets loop: move every key out of .env files committed to the repo and into a managed vault like Doppler, Infisical, or HashiCorp Vault, and set a rotation cadence. Supabase service_role: ninety days. Third-party API keys with active webhooks, such as Stripe or Resend: ninety days. Third-party API keys without signing secrets, such as OpenAI and Anthropic: thirty days. OAuth provider secrets: follow the provider's guidance, usually ninety days for Google and GitHub. Write the cadence into a calendar now, because the first rotation after launch is the one most teams miss.

Observability and the Surprise Bill

A live app without observability is a black box with a credit card attached. Items nine through twelve turn on the lights and put a cap on the bill.

Sentry, or an equivalent like Highlight or Bugsnag, belongs in every Lovable deployment from day one. Install it, upload source maps so stack traces resolve to the actual component name instead of a minified letter, attach the authenticated user ID and email to every event so you can tie an error back to a support ticket, and tag each release with the Git commit SHA so you know which deploy introduced a regression. The difference between a user emailing you "your app is broken" and Sentry telling you exactly which line of which component threw on which browser is the difference between an afternoon of debugging and a five-minute fix.

Supabase logs need to flow somewhere queryable. The platform retains logs for seven days on the free tier and longer on paid, but the native dashboard is painful for searching. Configure a log drain to Axiom, BetterStack, or Datadog. The most valuable query you will run in that tool is the one that surfaces RLS policy violations: these appear as permission denied errors and indicate either an honest UX bug or an attacker probing your schema. A sudden spike in RLS denials on a table is a signal to investigate within the hour.

Cost monitoring is item eleven and the one that surprises solo founders most. Supabase bills on egress, and egress is bandwidth leaving the database, which means every image served from Storage, every SELECT that returns large JSON columns, and every realtime subscription counts. The free tier includes five gigabytes of egress; beyond that, the rate is around nine cents per gigabyte. A single product launch that goes mildly viral with unoptimized images can produce a four-figure bill overnight. Set the budget alert in the Supabase dashboard at eighty percent of your plan threshold and make sure the notification email goes to someone who reads email on weekends. Mirror the alert on Vercel or whichever hosting platform you use, and set a hard spend cap where the platform supports one.

Legal Pages, Consent, and Analytics That Actually Respect Users

The last three items are where most vibe coders roll their eyes and where most lawsuits and platform removals originate. You do not get to skip them because you are small. The California Privacy Rights Act, the GDPR, and the Apple and Google payment guidelines all apply the moment you take the first dollar.

Legal pages, item thirteen, means a privacy policy, terms of service, and a data processing addendum linked from the footer of every page. Generating these by hand is a lawyer's job you cannot afford; generating them from Termly, iubenda, or GetTerms is a ten-minute job that produces policies with ongoing updates as regulations change. Both services will scan your site, detect the third-party services you actually use, and produce a policy that names them by name, which is what the GDPR and CPRA both require. Update the policy every time you add a new integration.

Item fourteen is the consent banner, and this is where a SERP of generic advice will steer you wrong. The minimum bar used to be a cookie banner with Accept and Reject buttons. That bar moved in 2024 when California began enforcing Global Privacy Control honoring under the CPRA. GPC is a browser signal, a Sec-GPC: 1 header that Firefox and Brave send by default and that Chrome users can enable via an extension, and the signal is legally equivalent to a Do Not Sell request for any California resident. If your consent banner ignores it and loads analytics anyway, you are in violation, and the state Attorney General has issued fines ranging from twenty-five hundred to seventy-five hundred dollars per affected user. Cookiebot honors GPC only on its paid tier, which surprises teams who grabbed the free script. Osano, Termly, and OneTrust honor it on their free tiers. Choose accordingly, and test by opening your site in Brave with shields up and confirming no analytics pixels fire before consent.

Analytics, item fifteen, is the instrumentation that proves your product is working. PostHog, Plausible, and Fathom are the privacy-first options most Lovable apps pair naturally with; GA4 is the incumbent and requires more consent plumbing to run legally in the EU. Whichever you choose, turn on IP anonymization at the property level, gate the script behind the consent banner so it does not load until the user accepts, and configure a single conversion event that matters more than page views. For most apps that event is activated, which you define as the moment a user crosses from trialing to deriving real value: a first project created, a first document saved, a first teammate invited. Without that event defined, your analytics tell you that traffic is up and tell you nothing about whether the product works.

What to Do With the Checklist

Before the checklist, a word on sequencing. Some of these items take time to propagate and cannot be done the afternoon of launch. DNS records for SPF, DKIM, DMARC, and the Return-Path CNAME take anywhere from minutes to twenty-four hours to resolve globally, and Gmail in particular caches negative lookups, so a record that looks correct to you can still be evaluated as missing for a recipient for several hours. Add those records a week before launch and verify them with Google Admin Toolbox and MXToolbox well before you send the first real email. Similarly, the Supabase budget alert only triggers on the billing cycle it is configured in, so setting it the day of launch means your first warning arrives after the first overage bill. Configure alerts the moment the Supabase project is created, even on the free tier, so the numbers are familiar before they matter.

The other sequencing point is the rotation schedule. Writing "rotate service_role in ninety days" into a Notion doc that nobody opens is the same as not writing it. Put every rotation date as a calendar event with a thirty-minute block and an assigned owner, and include a link to the runbook that explains which environment variables need updating in Vercel, Doppler, and your Edge Functions after the new key is generated. The first rotation is the one most teams miss, because it arrives three months after launch when everyone has moved on to building features.

Print the fifteen items and run them as a sit-down review the day before launch. Flag any item that cannot be verified with a screenshot or a command output, and treat those as blockers. A launch that slips by forty-eight hours because the DKIM Return-Path CNAME is still propagating is a launch that keeps the inbox placement you paid for. A launch that ships on time with RLS off on the payments table is the launch that ends the company.

If you would rather not do the review yourself, the Lovable pre-launch engagement at WitsCode runs this exact checklist on your project, fixes every red item, hands back a clean report with the evidence for each green check, and charges a flat fee delivered inside seventy-two hours. No retainer, no hourly billing, no surprise scope. You send us the Lovable project URL, we send back a production-ready app.

> Book a Lovable pre-launch review with WitsCode and ship with every one of these fifteen items verified green.