Partly fixable yourself. Often an access rule you can fix in the Supabase dashboard.
- How serious
- High
- Fix it yourself?
- Partly, some steps need a developer
- Typical cost
- $49–$800 one-off check, or €99–$990 for a single fix (prices)
- Top rated for Lovable
- Afterbuild Labs · 10.0/10
What you see. You press Save, the button spins or resets, no error appears, and the data never shows up in the database.
Why it happens
The Supabase client does not throw when a save fails. It returns an object with data and error. AI-built forms often take the data, never look at the error, and reset the form as if it worked. So the user sees success and nothing is stored.
The most common error behind it is row level security, the per-table access rules. Once RLS is on, nothing is readable or writable through the API until a policy allows it. An insert without a matching policy fails with code 42501, new row violates row-level security policy. Other causes are a required column the form does not fill, a table that was renamed, or a user who is not actually signed in so auth.uid() is empty. Reads blocked by a policy return zero rows without any error, so a save can also work and then be invisible.
Fix it yourself
- On the live site press F12, open Network, submit the form, and click the request to
rest/v1/yourtable. 401 or 403 means an access rule, 400 a column problem, 201 means it saved. - In Supabase open Table Editor and look for the row. Then open the table's Policies. If there is no INSERT policy for signed-in users, add one with the check
auth.uid() = user_id. - Open Logs and pick API Gateway and Postgres to read the exact error text around the time you submitted.
- Ask your builder: After every insert, update and delete, check the error object and show its message to the user. Never reset the form before the save succeeds.
- Confirm the live site uses the same Supabase URL and publishable key as the preview, in your host's environment settings.
- If the error names a policy, use our RLS insert page. If the row exists but never shows, see data saves but never shows up.
When to get an engineer
Get an engineer when several forms fail, when you cannot tell which table the form writes to, or when adding a policy makes other users see each other's rows. Tell them the table name, the request status from the Network tab, and whether the row appears in the Table Editor. A one-off check is $49–$800 and a single fix is €99–$990, about two days. Ask them to add error messages to every form while they are in there.
Top-rated companies for Lovable apps
Ranked by our score: published prices, scope of work, AI tools named, timing and a low-risk first step. How we score.
- 1Afterbuild Labs10.0/10Best for: A check before launchFree first step · from $49
- 2Redlab10.0/10Best for: A full rescue by one team that keeps buildingFree first step · from $490
- 3Vibe Code Rescue (Lev Arakelyan)9.0/10Best for: A one-off check and a cleanupFrom $299
Check these
Access rules are on for every table
In Supabase, open Table Editor: every table should show RLS enabled, with at least one policy. In Firebase, your rules should never say allow read, write: if true.
One user cannot open another user's records
Sign in as user A, copy a request from the Network tab, and change the record ID to one that belongs to user B. You should get an error or an empty result.
Input is validated on the server
Forms that only check input in the browser accept anything sent directly to the API.
Errors reach you before users do
Add error monitoring and uptime alerts. If you learn about outages from customers, this is missing.
Questions
Can I just turn RLS off to make the form work?
No. With RLS off anyone with your public key can read and change the whole table. Add a policy for the action you need instead.
Why did it work in the builder's preview?
You were probably testing while signed in as the owner, or the preview pointed at a different project where the policy existed.
Sources: Supabase: row level security; Supabase: logs; Lovable: troubleshooting.
