Built with Lovable?
Your Lovable app works in the preview. It breaks in production.
Lovable is genuinely good at getting a working product in front of you. What it does not do is the unglamorous production layer: locking your database down, keeping secrets out of the browser bundle, making payments survive a retry, and making the deploy work somewhere other than Lovable's own hosting. Those are the things that break the week you put real customers on it, and they break in the same handful of places nearly every time.
Fixed £4,500 · 3 days · pass-or-refund · next slot w/c 3 August
What actually breaks
- Row level security is off, or the policy is effectively `true`This is the single most common one. Lovable wires up Supabase tables quickly, and the policies either never get written or get written permissively so the app keeps working during the build. The result is that any signed-in user can read every row in the table, including other customers' data, straight from the browser with the anon key.
- Secrets inlined into the browser bundleVite inlines any environment variable prefixed with VITE_ directly into the JavaScript it ships. A service role key, a Stripe secret, or a third-party API key added that way is readable by anyone who opens dev tools, and rotating it is the only fix once it has shipped.
- The anon key doing work the service role should doOperations that must be trusted (granting access, adjusting balances, writing audit rows) end up running client-side under the user's own permissions, which means the user can run them too, with whatever arguments they like.
- Edge functions and webhooks accepting anythingSignature verification is the step that gets skipped. An unverified webhook endpoint is a public API that grants whatever the webhook grants, to anyone who finds the URL.
- Auth works on the happy path onlySign-in works because you tested sign-in. Email confirmation, password reset, expired sessions, and the redirect back from a magic link are the flows that fail on a real customer at nine in the evening.
- It deploys to Lovable and nowhere elseMoving to your own domain or infrastructure surfaces everything that was implicit: environment variables that were only ever set in Lovable, build steps that assumed the preview, CORS and redirect URLs pinned to the preview domain.
How I work in a Lovable project
I never touch the builder. Lovable syncs your project to a GitHub repository you own, two ways, on the default branch. I take read and write access to that repository, work in it the way any engineer works in a codebase, and push back. Your project stays in sync and you keep using Lovable afterwards. The one rule during the sprint is that you stop prompting in the builder while I'm in the repo, because the sync runs on main and we would stand on each other. Anything you want changed, you tell me and I do it.
What “done” looks like
We agree one of these in writing before you pay anything. If it passes, the sprint passed. If it doesn't, you get a full refund and keep the work.
- A second customer, signed into a different organisation, cannot retrieve the first customer's records by any route, including direct ID guessing, and a test proves it.
- No secret is present in the shipped browser bundle, and every key that was exposed has been rotated.
- Sign-up, email confirmation, password reset and session refresh all complete against the production domain.
- The application builds and deploys to your own infrastructure from a clean checkout, with no step that only works from your machine.
We agree the acceptance test before any work starts. If it doesn't pass within three working days, you get a full refund and keep every change I've committed. The risk is mine, not yours.
Other things that block launches
- Stripe took the money. Your customer got nothing.
- Your Bolt.new app runs fine in the preview. The published version doesn't.
- Your Replit app works in the workspace. The published version doesn't.
- Your v0 app looks ready to ship. The part that breaks is the part you can't see.
- Your Base44 app works when you use it. It breaks when your customers do.
- Your Cursor app runs on your machine. That is the only place it has ever been tested.
- Your customers can see each other's data. It is never just the one screen you found.
- Users can't sign in. It worked every time you tested it.
- It runs on your laptop. It will not deploy anywhere else.
- Your AI feature is impressive when it works. You can't put it in front of a customer.
- The full The Launch-Blocker Sprint