I reviewed 14 Lovable/Bolt/Cursor MVPs in the last 6 weeks. Same 5 things are killing them in production

Most of these were AI SaaS founders who shipped fast on Lovable or Bolt, got their first 30 to 50 users, and then watched the whole thing start leaking. The patterns repeat almost exactly. Row Level Security written once, never tested. The default RLS policies in Supabase pass the demo. They fail the moment a user with a weird role hits a shared table. 4 of the 14 had policies that let any authenticated user read other tenants' rows. Nobody caught it because nobody wrote a test that pretended to be the wrong user. Auth flows that look fine until refresh tokens expire. Most use a single Supabase auth helper, never handle the refresh path, and silently log users out at 60 minutes. The founder thinks they have a churn problem. They have a session bug. Background jobs running on the same connection pool as the app. One newsletter blast or one CSV import locks the database for everyone. 6 out of 14. The fix is 3 lines of config. Nobody knows to look. Schemas built by prompting, not by thinking. Tables named like sentences. Foreign keys missing. JSONB columns holding data that should be relational. Once you have 500 rows of real customer data, every migration becomes a 4-hour problem. No idempotency on anything that touches money or external APIs. Stripe retries a webhook, you double-charge a customer, you find out from a Twitter complaint. Same pattern with email sends, SMS, third-party syncs. None of this is a code quality problem. It is a design problem that AI builders cannot see because the AI does not know your business yet. The fix is rarely "rewrite everything." It is usually 2 to 3 weeks of targeted infrastructure work: real RLS tests, a job queue, proper session handling, schema cleanup, idempotency keys where they matter.