DEV Community: fixier

From Prototype to Production: A Layered Checklist for Apps Built with Lovable, Bolt and v0

fixier — Fri, 06 Nov 2026 02:31:16 +0000

“It works” is the standard a prototype has to meet. Production adds a harder one: it keeps working for strangers, under load, when something fails, and when you are not looking. AI builders get you to the first standard quickly, which is exactly why teams skip the second.
The fix is a layered review. Instead of one vague “make it secure” pass, work through the layers in order, because failures in lower layers (data, auth) make higher layers (UX, SEO) irrelevant.

Layer 1: Data access and authorization
Verify that every table, view, function and storage bucket enforces who can see what. Test with two accounts and an anonymous visitor. This is the layer where the most damaging bugs live.

Layer 2: Authentication and sessions
Check password reset flows, email verification, session expiry, OAuth redirect URLs and what happens when a user is deleted. Confirm that sensitive routes are protected on the server, not just hidden in the UI.

Layer 3: Secrets and configuration
Separate public and private keys, use different credentials for staging and production, and confirm that nothing sensitive is in the client bundle or the repository history.

Layer 4: Input validation and payments
Validate on the server. If money is involved, compute totals server-side, verify webhook signatures, and make payment handlers idempotent so a retried webhook cannot grant access twice.

Layer 5: Dependencies
AI tools sometimes pull in outdated, abandoned or unnecessary packages, and in rare cases suggest package names that do not exist or are typosquatted. Review the lockfile, remove what you do not use, and run an audit tool such as npm audit.

Layer 6: Database performance and integrity
Prototype data is tiny; production data is not. Look for missing indexes on columns used in filters and joins, queries that run inside loops (the N+1 pattern), unbounded list endpoints without pagination, and missing foreign keys or constraints that let bad data in.

Layer 7: Errors, logging and monitoring
If you do not know it broke, you cannot fix it. Add error tracking, structured logs, uptime checks and alerts that reach a person. Replace silent catch blocks with handling that reports the failure and shows users something useful.

Layer 8: Deployment and environments
Confirm that the app behaves the same on your host (Vercel, Cloudflare, Railway or Fly.io) as it did in the builder preview. Check environment variables, build settings, caching, and that migrations run in a controlled order. Enable backups and actually test a restore.

Layer 9: Reliability under real conditions
Try slow networks, double clicks, expired sessions, empty states and large inputs. Load-test the two or three endpoints that matter most, not the whole app.

Layer 10: Discoverability and accessibility
Single-page apps generated by AI tools often ship weak metadata, no sitemap and poor semantic markup. Fix titles, descriptions, canonical tags, heading structure, alt text and keyboard navigation. These are the last layer, not the first, but they decide whether anyone finds and can use the product.

How to use the checklist
Work top to bottom, record each finding with a severity, and fix by severity rather than by how easy the fix is. Re-run the layers after any large AI-generated change, since regeneration can quietly undo earlier fixes.

A team that has built many such apps will tell you the same thing: the issues are rarely exotic. They are ordinary gaps that no one was assigned to look for. For a longer version of this process, see Fixier’s 13-layer production check and vibe coded app audit guide.

Aakshar works at Fixier, a team that audits, fixes and supports apps built with Lovable, Bolt, v0 and Cursor. Learn more at fixier.co.

Fixing vibecoded website's errors

fixier — Fri, 06 Nov 2026 02:03:34 +0000

fixier

Nov 6

Why AI-Generated Supabase Apps Leak User Data, and How to Audit Row-Level Security Before Launch

#ai #vibecoding #security #webdev

3 min read

Why AI-Generated Supabase Apps Leak User Data, and How to Audit Row-Level Security Before Launch

fixier — Fri, 06 Nov 2026 02:00:44 +0000

AI app builders are very good at producing screens, forms and working demos. They are far less reliable at the part nobody sees: who is allowed to read which row. In a typical Lovable or Bolt app backed by Supabase, the browser talks almost directly to Postgres. That means Row-Level Security (RLS) is not one security layer among many. It is the only thing standing between one user and everyone else’s data.
The anon key is public by design
Founders often panic when they see the Supabase anon key in their browser bundle. That key is meant to be public. The real question is what that key is allowed to do once someone copies it. If RLS is off or too loose, anyone can open the browser console and query your tables with the same client your app uses.

Six RLS failures that show up again and again in generated code

RLS was never enabled. Tables created through SQL migrations do not have RLS switched on automatically. A generated migration that creates a table but skips alter table ... enable row level security ships an open table.
Policies written as using (true). The AI makes the “permission denied” error go away by adding a policy that allows everything. It works, and it also exposes every row to every logged-in user (or to anonymous visitors, if the policy targets anon).
INSERT policies that do not bind ownership. A policy with with check (true) lets a user insert a row with someone else’s user_id. Pair it with a permissive select policy and you have impersonation. Ownership must be enforced in the check clause: alter table orders enable row level security;

create policy orders_select_own on orders
  for select to authenticated
  using ((select auth.uid()) = user_id);

create policy orders_insert_own on orders
  for insert to authenticated
  with check ((select auth.uid()) = user_id);
Wrapping auth.uid() in a subselect also lets Postgres evaluate it once per query instead of once per row, which matters as tables grow.

Authorizing on user_metadata. Claims inside user_metadata can be edited by the user. A policy such as “role is admin in user metadata” can be satisfied by the user themselves. Authorization data belongs in app_metadata or in a server-controlled table.
Views and functions that bypass RLS. A view runs with the privileges of its owner by default, so it can return rows that the underlying table’s policies would block. On Postgres 15 and later, create views with security_invoker = true. Treat every security definer function as a potential policy bypass and review its inputs carefully.
Storage buckets and the service role key. Public buckets and missing policies on storage.objects leak uploads such as invoices and IDs. Worse, generated code sometimes uses the service role key in client-side code. That key bypasses RLS entirely and must live only on the server.

A practical pre-launch audit

Inventory tables without RLS. Start with a query that lists them: select tablename from pg_tables where schemaname = 'public' and rowsecurity = false;
Read every policy as an attacker. For each one, ask: who can run this, what rows can they touch, and can they change ownership columns?
Test with two real users. Sign in as user A, create data, then try to read, update and delete it as user B. Repeat as an anonymous visitor. This catches what policy review misses.
Check the exposed surface. Search the built JavaScript for service_role, review RPC functions callable by anon, and confirm storage bucket visibility.
Use the platform’s own advisors. Supabase’s security advisor flags several of these issues, but it cannot know your business rules. A table can be correctly “protected” and still allow the wrong person to see it.

Make it permanent
RLS bugs return whenever an AI tool regenerates a migration. Put policy tests in CI: create two test users, run queries under each role, and assert that cross-user access fails. Supabase supports pgTAP tests through its CLI, so a failing test can block the deploy that would have reopened a table.

Takeaway
If your app has user accounts and was built mostly by prompts, treat RLS as the first thing to verify, not the last. For a deeper walkthrough, see Fixier’s Supabase RLS checklist and the guide on users seeing each other’s data.
Jiya works at Fixier, a team that audits, fixes and supports apps built with Lovable, Bolt, v0 and Cursor. Learn more at fixier.co.