u/Duck-Entire

Posted here a while back asking what RLS checklist people run before shipping. Kept digging since, and the pattern that shows up more than "RLS is just off" is worse: RLS is on, with a policy like using (true) with check (true).

That passes literally every naive check — Supabase's own advisor, a quick eyeball review, and (this is the part that surprised me) even a prompted AI review asking "did you set up RLS properly?" All of those confirm RLS is enabled. None of them confirm the policy does anything.

The other repeat offender: RLS enabled correctly in an early migration, then silently disabled by a later cleanup migration months down the line, with nobody re-checking because nothing prompts a re-check.

Genuinely curious from people running production Supabase apps — do you have anything that re-verifies policies after the fact, or is it a one-time check at build time and then trust?

I’ve been reviewing a bunch of public Next.js/Supabase repos recently, and the most common production-risk pattern was not broken code.

It was code that worked locally, but had weak data boundaries.

The patterns I kept seeing:

- tables created in migrations without RLS enabled

- RLS enabled but no meaningful policy added

- UPDATE/SELECT policies that were too broad

- auth checks happening in UI/client logic but not near the actual mutation

- routes trusting client-provided userId/orgId/accountId

- service role usage drifting into application code where it did not belong

The scary part is that most of these apps would pass a normal “does it work?” test.

The UI loads.

The query returns data.

The mutation succeeds.

The deploy passes.

But the app is still not necessarily safe to ship.

For people building production Supabase apps, what is your actual pre-launch checklist?

Do you manually review every table/policy/mutation path, or do you rely mostly on Supabase advisors and testing the happy path?

Hey everyone,

I’m currently building an open-source/local AST background daemon called PreFlight to catch silent schema drift and security-boundary leaks in real-time as you type.

To test out the parsing engine, I ran a scan against the official clerk/clerk-supabase-nextjs starter repository. While it threw a hard block on a bunch of unpinned latest dev dependencies (standard boilerplate behavior), it highlighted a massive structural challenge that anyone using Cursor, Claude, or v0 faces daily.

The codebase explicitly tells developers in the README that they must manually configure Supabase RLS policies. However, because starter repos rarely include local SQL migration or seed files, a local scanner has absolutely no way to mathematically verify if your auth boundaries are actually safe before you push to production.

When you let AI agents write or modify your database schemas, they constantly introduce silent RLS drift because they lack context on the external auth middleware layer (like Clerk's token injection). It writes syntactically perfect TypeScript that is fundamentally insecure at the database level.

What I'm changing about my approach because of this scan: I realized a local daemon can't just look at the application layer code. To actually protect developers from AI hallucinations, the AST engine needs to actively bridge the gap between your editor, your local migration files, and your auth middleware configurations.

I'm currently in active beta and pushing updates to our local daemon engine. Because it's a fresh launch, I don't have a social following or marketing budget, so I'm just putting the tool out there for peer review.

Quick Disclaimer: The tool is still a beta assistant meant to empower senior developer oversight—it doesn't guarantee 100% error elimination, but it acts as a solid automated guardrail.

I set up a temporary public build for the weekend if anyone wants to grab a key and test the engine on their local dev stacks. I'll drop the live link in the comments below to avoid tripping the spam filters.

Would love to get some honest feedback from anyone running a heavy Supabase + Next.js stack on how you're currently catching silent RLS changes before they hit production!

Hey everyone,

Like most of you, I've been heavily using Cursor and Claude to ship features faster. But the sheer velocity of AI generation means human code review has become a massive bottleneck.

The breaking point for me was realizing AI agents consistently mess up Supabase specifics. They confidently inline service_role keys inside route handlers, escalate privileges via NEXT_PUBLIC_ variables, or write Row Level Security (RLS) policies that look syntactically correct but silently expose data or allow using (true) updates.

I got tired of reverse-engineering broken AI code, so I built PreFlight to act as a local safety gate.

How it works:

• Local-First Interception: It doesn't run regex. It uses Tree-sitter for offline AST (Abstract Syntax Tree) parsing right in your terminal to catch the structural mistakes Claude/Cursor silently inject.
• AI Cloud Remediation: When it catches a leaked token or an absent authorization scope, it securely routes the context to a cloud proxy to generate a multi-file git diff patch that you can review and apply instantly.

Check it out:

• Website: https://preflight-vibe.vercel.app
• GitHub: https://github.com/av29nassh-sketch/PreFlight
• NPM: npm install -g preflight-pro

I’m looking for early beta testers. If you want to throw it at a test repository, drop a comment or shoot me a DM. I am manually handing out beta keys with AI fixes to keep our API costs from exploding while we test.

I’d love to know what gnarly Supabase edge cases or broken RLS policies the AI agents have generated for you lately, and feel free to completely roast the architecture!

I built PreFlight because I kept running into the same problem with AI-generated code:

it works, but I don’t fully understand what changed until it breaks somewhere painful.

PreFlight is a local-first safety tool for AI-generated code. It’s meant to catch issues like:

- hardcoded secrets

- auth / permission mistakes

- missing Supabase RLS

- unsafe route logic

- “works locally, breaks in prod” failures

I’ve been tightening it based on feedback, and I’m now looking for 5–10 serious beta testers.

What I’m offering:

- 14 days of full hosted access for free

- direct support from me

- early access while I’m still shaping the product

What I’m asking in return:

- use it on a real codebase

- send 2 short feedback check-ins

- be honest about what feels useful, noisy, confusing, or broken

Website:

https://preflight-vibe.vercel.app

Repo / free version:

https://github.com/av29nassh-sketch/PreFlight

If you’re interested, comment or DM me with:

- what kind of project you’re building

- what AI coding tools you use

- whether you’d genuinely be up for testing it for 2 weeks

Use this for r/betatests

Title: Looking for 5–10 beta testers for an AI code safety tool

I’m looking for 5–10 serious testers for PreFlight.

It’s a local-first tool designed to catch risky AI-generated code issues before deploy, especially in Claude / Cursor / Copilot workflows.

Things it focuses on include:

- exposed secrets

- auth mistakes

- missing Supabase RLS

- unsafe route logic

- “works locally, breaks in prod” issues

Beta details:

- 14 days free

- full hosted access

- repo/free version also available

- I’m looking for real usage and honest feedback, not just signups

Website:

https://preflight-vibe.vercel.app

Repo:

https://github.com/av29nassh-sketch/PreFlight

If interested, comment or DM me with your stack and what kind of project you’d test it on.