Lovable to Production: The 30% That Will Eat Your Weekend

Lovable is genuinely good at the first seventy percent. You describe the product, the chat scaffolds a working React and Supabase app, Stripe shows up in a few prompts, and a preview URL is live before lunch. The shape of the thing exists. What Lovable is not good at, and what almost no AI web app builder is good at in 2026, is the remaining thirty percent that separates a preview from a product you can hand to paying customers. That thirty percent is authentication that actually holds up to corporate email filters, Stripe integration that survives a real billing cycle, row level security that does not leak customer data across tenants, email that does not land in the spam folder, error monitoring so you find out about bugs before your users do, and edge-runtime debugging for the handful of things that only break in production. Each of these areas has a specific failure mode that Lovable ships with, a specific fix, and a specific amount of time it will eat if you try to do it on a Saturday after a coffee. We rescue Lovable apps every week at WitsCode, and the same six things come up every time. Here is what each one really costs, what the fix looks like, and why the SERP results you will find when you search for any of this are mostly wrong.

Magic-Link Auth Does Not Scale Past Low-Trust MVPs

The single most common Lovable default is magic-link passwordless authentication. It ships because it is the fastest path to a working login screen and because Supabase makes it one line of code. It is also the first thing that breaks the moment a real user tries to sign up from a corporate Outlook inbox. Microsoft Safe Links, Proofpoint, and Mimecast all prefetch URLs in incoming email to scan them for phishing, and the act of prefetching a single-use magic-link token invalidates it before the user ever clicks. The user sees a working email, clicks the link, and lands on an error page saying the token is already used. This is not a rare edge case. For any B2B product with customers in finance, healthcare, legal, or enterprise, this affects a double-digit percentage of signups. The fix is to add a proper email and password flow with verification, wire up password reset templates that Lovable does not generate, enforce email confirmation before allowing any paid action, and layer in at least one social provider with correctly configured redirect URLs on the Supabase side. You also need to swap localStorage session storage for a proper server-side cookie bridge so that Next.js server components do not hydrate with a flash of unauthenticated content. None of this is hard individually, but Lovable surfaces none of it in the builder, and the Supabase free tier rate-limits you to four auth emails per hour on the default shared SMTP, which means you cannot even test it properly until you bring your own sender. Realistic time to close this gap is between six and ten hours for a developer who has done it before, and usually a full weekend for someone who has not. The specific moves are predictable. Turn on email-and-password in the Supabase auth settings and disable signups without confirmation. Write the password reset email template, because Lovable does not generate one, and wire the reset and update flows through a dedicated route. Add Google OAuth as a secondary option and set the exact redirect URL in both the Google Cloud console and the Supabase provider settings, because Lovable never surfaces that the two have to match to the character. If you have a B2B product, add Microsoft OAuth as well, because enterprise customers will not create another password. Upgrade off the shared SMTP to your own Resend or Postmark sender before you start testing, otherwise you will hit the rate limit three emails in and waste an hour wondering why nothing is arriving. Finally, if the product handles anything sensitive, add TOTP-based MFA through Supabase's factor API, because magic links alone do not pass even a light security review from an enterprise buyer.

The Stripe Webhook Signature Verification Gap

Lovable will scaffold a Stripe checkout session and a webhook endpoint in about two prompts, and the result almost always looks correct. It is not. The most common failure, which we see in roughly four out of five Lovable apps that hit us for a rescue, is that the webhook handler calls request.json() to parse the incoming payload before passing it to stripe.webhooks.constructEvent(). Stripe requires the raw, unparsed body for signature verification, because the signature is computed over the exact bytes that were sent. Once you call request.json(), the body has been consumed and re-serialized, and every signature check will fail. In development this looks fine because Lovable generated output often swallows the verification error and processes the event anyway, which means your app appears to work. In production it means any attacker who can reach your webhook URL, which is public by definition, can forge subscription events and hand themselves a paid account. Beyond signature verification, the generated handler does not deduplicate on event.id, so Stripe's normal retry behaviour creates duplicate subscription rows. The customer portal for self-serve cancellation is not scaffolded. The invoice.payment_failed and customer.subscription.updated events are not listened to, which means when a card bounces you never downgrade the user. Automatic tax is off, which creates real compliance exposure in the EU and UK. Strong customer authentication for 3DS cards is not wired on the client side, so a chunk of European traffic simply fails to complete checkout. Fixing all of this properly, with raw body handling, idempotency keys, portal sessions, full event coverage, test-mode separation, and tax configuration, takes a competent developer about a day and a half. It is also the single area where getting it wrong costs real money rather than just embarrassment. The pattern we apply on every rescue is to rewrite the webhook route as a Node-runtime handler that reads the raw body as a Buffer before any JSON parsing, calls constructEvent with the signing secret from the environment, stores the event.id in a processed_events table with a unique index, and returns a 200 response before doing the actual work in a background task so Stripe does not retry on slow database writes. We then wire listeners for at least checkout.session.completed, invoice.paid, invoice.payment_failed, customer.subscription.updated, customer.subscription.deleted, and charge.refunded, because anything less leaves a hole in the billing state machine. The customer portal is a single Stripe API call once billing portal is enabled in the Stripe dashboard, and it needs its own Supabase edge function to generate the session URL scoped to the current user's Stripe customer ID. This is also the moment to split test and live keys into separate environment variable names so that a preview deploy can never charge a real card.

RLS Policy Auto-Generation Is Incomplete on Join Tables

Row level security is the feature that makes Supabase safe for multi-tenant apps, and Lovable does a reasonable job of generating policies on primary tables. When you describe a resource, the generator will usually write select, insert, update, and delete policies scoped to auth.uid() and the owning user column. Where it falls apart is on join tables, pivot tables, and any table that represents a relationship rather than an entity. A classic example is an organizations table, an organization_members pivot, and a projects table. Lovable will write policies for organizations and projects but often leaves organization_members with RLS enabled and no policies attached, which in Postgres means deny-all and silently breaks every feature that needs to check membership, or worse, leaves RLS disabled and makes the membership data world-readable. Storage buckets have the same problem. Public avatar buckets tend to be correctly scoped but user-uploaded documents, invoices, and exports are frequently left with permissive read policies because the generator cannot tell the difference between a public asset and a private one. Views are another common leak: the default security_invoker setting in recent Postgres means views can bypass the RLS of the caller if the view owner has broader access. The only reliable way to audit this is to write an explicit test suite that attempts cross-tenant access with two different user tokens and asserts that the second user cannot see the first user's data on every table, view, and storage path. We run this audit as a standard step in every Lovable rescue. On a medium-complexity app it takes three to six hours to write the tests and another few to plug the leaks they find, and we have never once audited a Lovable app where no leaks were found.

Supabase SMTP Defaults That Get Flagged as Spam

Email deliverability is the quiet killer of early-stage Lovable apps. Magic links, password resets, receipts, and onboarding emails all need to actually arrive in the user's inbox, and by default they do not. Supabase deprecated its shared SMTP service during 2024 and now requires projects to bring their own sender, which Lovable papers over by wiring in Resend through a native integration. The integration works, but it uses the default onboarding@resend.dev from address, which Gmail and Outlook filter aggressively because the domain has no relationship to the sending app. The 2025 Postmark deliverability benchmarks put unauthenticated domain inbox placement between sixty and eighty percent across the major providers, meaning a quarter of your transactional email is not being seen. The fix is to move to a real sending domain, configure DKIM, SPF, and DMARC records in DNS, set DMARC to at least quarantine after a warm-up period, and monitor for bounces and spam complaints by wiring the Resend webhook to a handler that pauses sending to hard-bouncing addresses. For higher transactional volume, we generally move clients off Resend onto Postmark, which still has the best inbox placement for transactional mail in our testing, or onto SES with a proper reputation management setup for anyone sending at real scale. Resend is a fine developer experience for getting started, but it is not where you want to be when you are trying to convince a churning customer to come back. Budget four to six hours for a proper deliverability setup including DNS propagation time and a domain warm-up schedule.

Sentry Integration Into Lovable-Generated Next.js

Lovable does not wire up error monitoring at all, which is perhaps the single biggest silent risk in a shipped app. Your users hit a broken state, they do not tell you, they just leave. Sentry is the obvious answer and the integration is straightforward in theory, but the Lovable-generated Next.js scaffold needs specific handling. Current Next.js expects Sentry to register through an instrumentation.ts file at the project root, with the register function routing to different config files for Node, edge, and client runtimes. Each runtime needs its own Sentry init because the edge runtime does not support the full Node SDK. If you only register the Node and client versions, which is what most Sentry tutorials show, every error thrown in middleware or in an edge-runtime route handler goes unreported. Server actions are another subtle miss: unhandled rejections inside a server action do not propagate to the default Next.js error boundary and will not appear in Sentry unless the app is wrapped with withSentryConfig in next.config.js and the action is called from a properly instrumented client. Source maps need the SENTRY_AUTH_TOKEN environment variable at build time and the Sentry webpack plugin wired through the Next config, otherwise stack traces in production are minified and useless. Session replay is worth enabling for low-traffic B2B apps but adds roughly two hundred kilobytes to the client bundle, so it needs sample-rate tuning. A full Sentry integration on a Lovable-generated codebase takes about three hours for someone who has done it before, and it is one of the highest leverage things you can add because it changes your relationship to production bugs from reactive to proactive overnight.

The Edge Runtime Versus Node Runtime Debugging Gap

The last gap is the one that causes the most confusion because it only shows up after deployment. Next.js App Router runs middleware in the edge runtime by default, route handlers in Node unless you opt into edge, and server components in Node. Lovable's generator is inconsistent about which it picks for which handler, and the failure mode is that code which works perfectly in the local preview breaks silently in production. The edge runtime has no Node fs, no Node crypto, no Buffer, and limited npm compatibility. Anything that reaches for a Node-only API in an edge context throws at cold start, and the error appears only in Vercel function logs, not in the browser and not locally unless you are running vercel dev with the correct runtime emulation. The Supabase client itself works in both runtimes but its cookie adapters differ: the edge version reads cookies from the incoming Request headers while the Node version uses next/headers, and mixing them up means sessions appear to work locally but return null in production. The Stripe Node SDK had a long history of CommonJS-only quirks and still fails in some edge contexts for complex endpoints involving file uploads. Our rule of rescue is to explicitly mark every route handler with export const runtime = 'nodejs' unless there is a concrete latency reason to use edge, then measure cold starts and selectively move the hot paths. Edge wins for simple redirects, auth checks, and geo-based responses where the fifty-millisecond cold start beats Node's three hundred. Everything else should stay on Node until proven otherwise. Actually finding and fixing the runtime mismatches in a Lovable-generated app takes between four and eight hours depending on size, and it is the single gap most likely to produce a support ticket from a confused founder whose app "worked yesterday."

What the Last Mile Actually Costs

Add the numbers up and the last thirty percent is roughly four to six full developer days, spread across six different specialisms, half of which most founders have never touched before. That is why a weekend is never enough. It is also why this is exactly the work we do at WitsCode. Our Lovable rescue engagement is a fixed-scope five-day sprint that covers all six areas above, ships a production-ready auth flow with MFA and password reset, wires a Stripe integration that passes a proper webhook security audit, writes and tests RLS policies on every table and bucket, configures deliverable email from your own domain with DMARC enforcement, installs Sentry across all three runtimes with source maps and alert routing, and audits every route handler for runtime correctness. You keep the codebase, you keep the Lovable project, you keep the ability to iterate in the chat afterwards. You just start the next iteration from a foundation that will not eat your weekend. If you have a Lovable preview URL and a Stripe dashboard with your first few test customers, you are exactly the person we built this for >> book a call from the homepage and we will have your app production-ready by Friday.