Lovable developer rescue · React, Supabase, Stripe
Fix your broken Lovable app.
Stuck in a prompt loop, broken after publishing, or not safe to put real customers through? A senior engineer finds what is actually wrong and fixes it, in code you own, without throwing away what works.
Photography is illustrative.
- Front end
- React: TanStack Start for projects created since May 2026, React and Vite before that
- Back end
- Lovable Cloud (built on Supabase) by default, or your own Supabase project
- Payments
- Lovable's Stripe integration, running in Edge Functions
- Code
- Two-way sync between one branch and a GitHub repository you own
Who this is for
For founders whose Lovable app works in the demo, and not yet for real users.
You built something real in Lovable. People can sign up, the screens look right, and maybe you already have a few customers. Then it stopped behaving: each prompt fixes one thing and breaks another, the published app does not match the preview, Stripe takes money without unlocking anything, or someone asked whether your database is safe and you were not sure.
That is the normal point to bring in an engineer, not a sign you chose the wrong tool. Lovable gives you a standard stack underneath: React in the browser (TanStack Start for projects created since May 2026, React and Vite before that), and Supabase, either through Lovable Cloud or your own project, for the database, sign-in and server functions. We write that stack every day, so we can read your app as ordinary code, find the cause rather than the symptom, and leave Lovable working for you afterwards.
Failure modes
The ways Lovable apps break.
These are the problems we look for first in a Lovable app, in roughly the order they cost founders the most. Most apps have two or three of them; none of them means starting over.
-
Row-level security switched off, or allowing everyone
- What you see
- Usually nothing: the app works. Sometimes Lovable's security scan or Supabase's advisor flags a table, or a user sees a record that is not theirs.
- What is actually wrong
- The browser talks to Supabase directly with the public (publishable or
anon) key, which every Lovable app ships. Row-level security is the only thing stopping that key reading every row. Tables created by SQL migrations do not get it switched on by default, and a policy likeusing (true)counts as a policy while protecting nothing. - How we fix it
- We list every table and storage bucket the public key can reach, write each policy against who should see the row, and prove it by signing in as one test user and trying to read and change another's data. Each policy gets a test that fails if isolation breaks.
-
Secret keys shipped to the browser
- What you see
- The app works, often right after a prompt like "fix the permission error". Then an OpenAI, Stripe or Supabase bill shows usage you do not recognise.
- What is actually wrong
- Everything in the browser bundle, including any
VITE_variable, can be read by every visitor; Lovable's own secrets store keeps keys out of it, but a key pasted into a prompt or into front-end code ends up there. A Supabaseservice_rolekey in the browser bypasses row-level security completely; a Stripe secret key or AI API key there can be used by anyone with developer tools open. - How we fix it
- We rotate every exposed key first, then move each call that needs a secret into an Edge Function with the secret in the backend's secret store, and check the built bundle so nothing secret is left in it.
-
Stripe payments that unlock on the wrong signal
- What you see
- Customers pay and get nothing, get access without paying, or keep access after cancelling. Test purchases in the preview turn out to be real charges. The Stripe dashboard shows webhook deliveries failing with 400 or 401.
- What is actually wrong
- Lovable's Stripe integration makes webhooks optional and leaves setting them up in Stripe to you, so many apps grant access when the browser reaches a success page instead of when Stripe confirms the payment. Where a webhook exists, it often never verifies Stripe's signature (verification needs the raw request body, so parsing it as JSON first breaks it), or it sits in an Edge Function that requires a signed-in user and so rejects Stripe, which sends no user token. And the preview has no test environment: with a live key, a preview payment is a real one.
- How we fix it
- One webhook function, with the user-token check turned off for that function alone and Stripe's signature verified instead, each event handled once, and subscription state stored on the server and used to decide access. We test checkout, renewal, failed payment and cancellation with Stripe's own tools.
-
Works in the preview, breaks once it is published
- What you see
- A blank page, an "Invalid API key" error, or sign-in links that send users back to the old address after you move to a custom domain or deploy the GitHub copy to Vercel or Netlify. Refreshing any page but the home page gives a 404.
- What is actually wrong
- With your own Supabase project, Lovable does not add a new custom domain to Supabase's auth redirect settings; you have to (on Lovable Cloud it is added for you once the domain is live). A host outside Lovable that lacks the build-time environment variables builds a broken app. And an older Vite project is a single-page app, so its host must send every route to
index.html. - How we fix it
- A written list of every variable for each environment, Supabase's auth URLs set for every real domain, rewrites for client-side routes, and a deploy that builds and smoke-tests the app before it goes live.
-
Sign-in loops and sessions that drop
- What you see
- Users bounce between the login page and the dashboard, are logged out on refresh, or open a password-reset link and land signed out.
- What is actually wrong
- Usually a protected route that decides before Supabase has restored the session from storage, several auth listeners working against each other, or confirmation and reset links nobody handles.
- How we fix it
- One place that owns the session and waits for it to load, one listener, explicit routes for confirmation and reset, all tested in a fresh browser and on a phone.
-
Admin checks that exist only on the screen
- What you see
- Ordinary users cannot see the admin page, so it looks secure.
- What is actually wrong
- Hiding a button is not access control. If the check lives only in React, or the user's role sits in a column the user can update, anyone can run the same Supabase queries from the browser console.
- How we fix it
- Roles stored where users cannot write them, enforced by database policies and by Edge Functions that check the caller's verified identity. The screens simply follow.
-
Prompt loops that rewrite working code
- What you see
- Every fix breaks something that worked yesterday. Credits go on the same error, and "Try to fix" goes round in circles.
- What is actually wrong
- The AI changes code without anything telling it which behaviour must stay the same. With no automated tests, a regression shows up only when a customer finds it.
- How we fix it
- We find the last good version, pin down what works with automated tests, fix the cause in the code, and add checks so a later prompt cannot quietly undo it.
-
One database for everything, and changes nobody can replay
- What you see
- You test on the same data your customers use. Changes made in the Supabase dashboard are not in GitHub, and nobody could rebuild the database from scratch.
- What is actually wrong
- Prototypes start with one Supabase project. Edits made in the dashboard or SQL editor are not migrations in the repository, so there is no record and no safe way to try a change first.
- How we fix it
- We capture the current schema as migrations, set up a separate project for testing, turn on backups, and make every later change a reviewed migration in GitHub.
Before you hire anyone
What to try yourself first in Lovable.
- Go back to the last version that worked. Lovable's version history restores the code from before things broke, which is usually faster than prompting forward from a broken state. It restores code only: database data stays as it is, so a bad data change needs its own fix.
- Give it the real error. Open the browser console (F12) and the Supabase logs for your Edge Functions and database, and paste the exact error into Lovable rather than "it's broken".
- Ask before it edits. Use Lovable's chat mode or plan mode, neither of which changes code, to have it explain the cause and propose a fix. Then make one change per prompt and check it before the next. Lovable's own advice is to press "Try to fix" once or twice, then switch to plan mode to find the cause; repeated blind fixes pile up code that hides the real problem.
- Run the security checks you already have. Lovable runs a quick security scan when you publish, but by default its findings do not block publishing, so read them. Run the deeper scan by hand, then the two queries in our row-level security note. Any table with security off, or a policy of
true, needs fixing before real users arrive. - Connect GitHub. Link the project to a GitHub repository you own, so a full copy of the code and its history lives outside Lovable. Any developer, including us, starts there.
- Rotate anything you pasted. Any secret key you ever pasted into the chat or into front-end code should be treated as public. Create a new one, and revoke the old one.
How we work
How we work on a Lovable app.
Lovable syncs a project with one branch of a GitHub repository, in both directions; pushes to other branches do not sync. We work in that repository, in our own branches, and merge into the synced branch only once a change passes review, so the project keeps working in Lovable and you can go on building with it after we hand back.
If the app runs on your own Supabase project, we work in it, with a separate project for testing. If it runs on Lovable Cloud, the default, we say on the first call whether moving to your own Supabase account is worth it. That move is manual (database, storage, sign-in settings and secrets), so it is your decision, never a default.
-
A free 20-minute call
You show us the Lovable app and tell us what is going wrong. We say what we expect to find, and whether a paid check is worth it yet.
-
Quick Security Check or App Readiness Review
A senior engineer reads the code and tests the running app: data access, keys, sign-in, payments, deployment.
You get Every finding in writing with its severity and fix; the review adds a keep, change or replace call for each part and a fixed quote.
-
Fixed-price fixes
Security & Data Hardening from $7,500, or Production Launch from $15,000, in your repository, with a test beside each fix.
-
Handover
Production kept apart from development, a deploy you can roll back, and notes so you, the tool or any developer can carry on.
Prices
Where to start, and what it costs.
-
App triage call
Free
20 minutes
-
Quick Security Check
$495
Delivered in 48 hours. The fee is credited toward the App Readiness Review.
-
App Readiness Review
$1,500 flat
5 business days. The fee is credited toward any fix booked within 30 days.
Fixes are priced after the check or review, at one fixed price before anything starts. The full price list and how fees are credited.
Proof
Who does the work.
A US software engineering firm. The founding team has taken a product off an AI app builder before (built, not yet in paid use) and runs a production telehealth platform on Supabase. We are an independent firm, not a Lovable partner or agency. Across the systems the team built and runs:
- 20,900+ automated tests across the systems the founding team built and runs
- 16,800+ CI runs automated builds and test runs on GitHub Actions
- 940+ merged pull requests across the same codebases
Counted from the repositories and CI history of the systems the founding team built and runs, 22 Sep 2026; each figure rounded down. How we counted
Questions buyers ask
Lovable questions, answered.
Can I keep using Lovable after you fix it?
Yes. We work in the GitHub repository Lovable syncs with, so our changes appear in your Lovable project. We add automated checks that every change, ours, yours or Lovable's, must pass before it reaches production, because an AI edit can undo a fix without anyone noticing.
Will you rewrite everything?
Rarely. Most of a Lovable app is worth keeping: the screens, the flows and much of the data model. The review marks each part keep, change or replace, with the reason, before any work is priced.
Is my Supabase data exposed?
Nobody can say without checking, including the scanners. Run the two queries in our row-level security note: any table with row-level security off, or a policy that allows every row, is readable with the public key your app already ships. The Quick Security Check tests this from the outside and tells you in writing. Check row-level security yourself.
How fast can you look at it?
The App triage call is 20 minutes and free. The Quick Security Check is delivered in 48 hours and the App Readiness Review in 5 business days. Security & Data Hardening usually takes 1 to 2 weeks.
Do you need my Lovable login?
No. We need read access to the GitHub repository and, for the review, access to the back end (your Supabase project, or Lovable Cloud through you) or its logs. Keep your Lovable account to yourself; it is how you keep building.
Are you a Lovable partner?
No. Oracis is an independent US software engineering firm, not affiliated with Lovable. We fix and finish apps built with Lovable, alongside apps from Bolt, Replit, Cursor and other tools.
What does it cost to fix a Lovable app?
The first call is free. The Quick Security Check is $495 and its fee is credited toward the App Readiness Review, which is $1,500 flat and credited toward any fix booked within 30 days. Security & Data Hardening is from $7,500 and Production Launch from $15,000, each at one fixed price set after the review. We never bill hourly on work nobody has sized. The full price list.
Send us the Lovable app.
The Lovable link or the GitHub repository, what is going wrong, and when you need it live.