Is the Supabase anon key supposed to be public?

Yes — the anon key is public by design. Your security comes from Row-Level Security, not from hiding the key. If RLS is missing or misconfigured, that public key becomes a master key to your database, which is the single most common failure we find.

Isn't a scanner enough to check my app?

A scanner checks patterns and known CVEs. It cannot tell whether your users can read each other's data, because that depends on your authorization logic across multiple files. Harvey reviews the whole codebase across ten modules and, on the paid tiers, stands up your stack to prove findings live.

How much does a Harvey audit cost?

The free scan is $0. Paid audits are priced by codebase size, measured automatically during the free scan: a Connected audit starts at $500 and a Full audit (which stands up and attacks a copy of your stack) starts at $1,000. Enterprise and regulated codebases are custom-quoted.

Do you need access to my database?

Not for the free scan — it runs on source only, no credentials. The Connected and Full audits read your production database read-only to confirm live state; if you decline, those checks are recorded as not run in the coverage ledger and the rest still runs.

Why do you keep fixing the same three files?

The pain this is for

"Every change to this part breaks something." "I fixed this bug last month and it's back." "One area of the app eats all my time, and I don't know why." Nobody searches for "churn times complexity" — but almost every founder running a fast-moving codebase has felt this exact pattern, usually without being able to point at the specific files causing it.

Why it's always the same three files

Four separate mechanisms compound on each other, and they tend to stack in the same few files rather than spreading out:

1. Hotspots: complexity and change collide

A file that is both complex (deep nesting, many branches, many responsibilities) and frequently changed is a hotspot — every edit has more ways to go wrong, and it gets edited more often than anywhere else. Ranking files by churn × complexity finds the small set that concentrates most of a codebase's bug risk, instead of treating every file as an equal suspect.

2. Duplication: you fixed one copy

Logic that was copy-pasted instead of shared drifts out of sync. A bug fix lands in the copy someone remembered to edit; the other copies keep the old, broken behavior — so the "same" bug reappears somewhere that was never actually touched.

3. Maintainability: fragile hand-rolled code invites the next bug

Hand-rolled auth, ad-hoc parsing, and other reinvented-wheel code tends to cluster in the same files as the hotspots above, and it is disproportionately fragile — a small change nearby has more ways to break it than code built on a standard, well-tested pattern.

4. Test quality: nothing catches it coming back

A regression returns silently when the tests around that file don't actually exercise the failure path. A green suite that never runs the code that broke — or asserts nothing meaningful when it does — is worse than no suite at all, because it's trusted.

A quick self-audit

Can you name, right now, the one or two files every recent bugfix has touched?
When you last fixed a bug, did you check whether the same logic was copy-pasted anywhere else?
Is there a part of the app new contributors are told to "be careful around"?
Does that area have hand-rolled logic where a standard library or pattern would do?
If you reintroduced last month's bug on purpose, would a test actually fail?
Have you ever ranked files by how often they change AND how complex they are — together?

This is the felt version of the entire code-health half of Harvey's audit in one pain: Hotspots (M3) ranks files by churn × complexity, Duplication (M4) finds the copies a fix missed, Maintainability (M6) flags the fragile hand-rolled code sitting in those same files, and Test quality (M8) runs mutation testing — deliberately breaking your code — to report which of your tests would actually catch the regression coming back.