Lovable shipped the product. We ship the parts users depend on.

What Lovable does well

Lovable produces polished, coherent applications with sensible structure, and its Supabase integration means the result usually has real persistence rather than mocked data. Teams get further before hitting a wall than with most generators — which means when they do hit it, they have real users on the other side.

• React + Vite
• Tailwind CSS with shadcn/ui
• Supabase (Postgres, auth, storage)
• Supabase Edge Functions
• Deployed on Lovable's hosting or Vercel

• 01

  Row-level security that passes a demo, not an audit

  Policies exist but are written per-table in isolation, so a join or a storage bucket exposes what the table protected. We test isolation adversarially — a suite that actively tries to read another tenant's rows — because that's what a customer's security questionnaire is really asking.

• 02

  Storage buckets left public

  Uploaded documents and images land in a public bucket with guessable paths. For anything user-generated this is a disclosure incident waiting for someone to notice the URL pattern.

• 03

  Edge Functions without input validation

  Functions trust their inputs because in the demo the only caller was the app's own UI. Once the endpoint is discoverable, unvalidated input is the whole attack surface.

• 04

  No tenant model, just a user column

  Multi-tenancy is approximated with a `user_id` filter, which breaks the moment a customer wants two seats. Retrofitting a real tenant model is the most common reason a Lovable app needs structural work rather than patching.

• 01

  Secrets in the client bundle

  API keys inlined into frontend code because the prototype had no server to hide them behind. Anyone can read them with view-source, and rotating them is the first thing we do.

• 02

  Authorisation checked in the UI

  The admin button is hidden from non-admins, and the endpoint behind it is wide open. Hiding a control is not access control, and this is the single most common serious finding.

• 03

  No migration history

  The schema exists because someone clicked through a dashboard. There's no record of how it got that way and no safe path to change it, so the first production schema change is terrifying.

• 04

  Nothing to catch a regression

  No tests, so the next AI-assisted edit that breaks checkout is discovered by a customer. This is what makes generated codebases feel fragile — not the code quality, the absence of a safety net.

1. 1

   Audit — 3 to 5 days

   Full read of the codebase, the Supabase schema and every policy, plus the storage configuration. Findings ranked by severity with a written fix-or-rewrite recommendation per area.

2. 2

   Isolation and tenancy

   A real tenant model where one is needed, RLS rewritten as a coherent set rather than per-table guesses, storage locked down, and an adversarial test suite that runs on every commit.

3. 3

   Server-side truth

   Entitlements, pricing and validation moved behind Edge Functions or a server runtime with proper input validation, so no rule that matters is enforced in the browser.

4. 4

   Billing and migrations

   Stripe subscriptions with metering and entitlement checks, and the schema captured as versioned migrations so changes stop being dashboard clicks.

5. 5

   Tests, CI and observability

   Playwright over the core journeys, GitHub Actions on every PR, Sentry and PostHog in production, and a documented handover.

1. Step 1 · Validate

   30-day Sprint

   Prove the use case before you commit. Working prototype on real data, eval scores, and an honest signal in 30 days. Fixed scope, fixed fee.

   $4,500 fixed

   Learn more
2. Most teams land here

   Step 2 · Build

   Prototype → Production

   Turn the validated prototype into a real product. Auth, DB, payments, tests, monitoring, deployed. Sprint fee credits toward this engagement.

   from $6,000

   Learn more

3. Step 3 · Scale

   Managed Retainer

   Ongoing operation, eval cycles, model iteration, and cost guards. We keep the system improving so your team can focus on growth.

   from $750/mo

   Learn more

FAQ

Lovable to Production: your questions.

• Our security questionnaire asks about tenant isolation. Can you answer it?

  That's the exact reason most Lovable teams call us. We build the isolation, then the adversarial test suite that demonstrates it, so the questionnaire answer points at a CI run rather than a paragraph of reassurance.

• Can we keep Lovable in the loop after this?

  For new UI, yes. We recommend it stops touching auth, data access and billing once those are hardened — those are the layers where a regeneration silently undoes a security fix.

• How do you handle the Supabase schema?

  We capture the current state as an initial migration and move all subsequent change into reviewed migration files. After that, schema changes go through the same pull request process as code, which is what makes them safe to make.

• Is the code still ours?

  Yes, entirely — repo, IP and the right to take it elsewhere, from day one. That doesn't change because we worked on it.

• Bolt to ProductionBolt gets you to a running product in an afternoon. We add the things it never had to think about — real auth, migrations, payments that can't double-charge, and a test suite that survives your next prompt.Read
• v0 to Productionv0 output is the best-looking starting point in the category, and it is almost entirely frontend. The work is building the system underneath it — and doing that without throwing away the UI you liked.Read
• Replit Agent to ProductionReplit Agent builds whole applications, backend included — which puts you further along than most generators. The catch is how much of it assumes it's running inside Replit.Read