Five mistakes · five fixes
If you built an app with AI, it probably works. And it's probably making a few of these. Every mistake below broke my own app first. Here's each one, the fix, and a 30-second check so you know you're safe.
One commit called "updates", or no repo at all. Git is the undo button for AI mistakes: without it, one bad session can erase your working app and there's no yesterday to go back to.
The 30-second check
Run git log --oneline. You should see many small commits, not one giant "updates".
API keys pasted straight into your files. Anyone with dev tools can read them. Scanners find hundreds of thousands of live keys on public GitHub every month.
The 30-second check
Run git ls-files | grep .env. If it prints anything except .env.example, rotate those keys today.
The 2,000-line page.tsx. Claude keeps appending because adding in-place is easiest, until it can't safely edit its own file, and neither can you.
The 30-second check
Sort your files by length. Anything over 600 lines is where your next bug is hiding.
A 2026 audit found 88% of vibe-coded apps had row-level security switched off. Any user could read every row. Nothing visibly breaks, so nobody notices until it's an incident.
The 30-second check
The two-account test: sign up twice, try to read account A's data from account B. If you can, so can everyone.
Your app has the same purple-gradient look as 80% of AI apps, and screens got built before anyone decided what the app is, so the data model shifts weekly and everything breaks.
The 30-second check
Can a stranger say what your app does in one sentence? If not, the page isn't written yet.
88%
of vibe-coded apps had their database publicly readable (2026 audit)
100k+
live API keys found on public GitHub every month
11%
of 20,000+ indie launches exposed database credentials in the frontend
2,535
lines in the worst file of my own v1. Every rule here broke my app first
The bonus round
The first five keep your app safe. These five keep it alive once real people use it.
You change something, click through the app, and hope. That is a ritual, not a test suite. Ask Claude to write a test before each fix, and run them automatically on every push.
The 30-second check
Break something on purpose. Does a robot catch it before you do?
Your app fails silently and you find out from a user screenshot days later. Wire an error tracker the day you deploy, with alerts that reach your phone.
The 30-second check
Throw a test error. Did anything tell you?
Three date libraries, two UI kits, npm install everything Claude suggests. Question every new install, keep one library per job, and prefer the platform when it is enough.
The 30-second check
Open package.json. Can you say why each line is there?
Every change goes straight to the app your users are on. Preview deploys give every branch its own private URL, free on most hosts. Test there, then promote.
The 30-second check
Can you try a risky change with zero users seeing it?
Pay-as-you-go keys everywhere, then a loop calls a paid API all night. Set spending caps and usage alerts on every paid service, and know what one active user costs you.
The 30-second check
Can you name your cost per user? If not, the bill will name it for you.
The bookshelf
Hunt & Thomas
The one-page-first mindset. Decide what you are building before the AI does.
Humble & Farley
Gates before features. Why automatic checks make you faster, not slower.
Robert C. Martin
One core, thin edges. Keep vendors at the door so you can swap them.
Martin Kleppmann
Receipts and idempotency. Why nothing important should be able to happen twice.
Steve Krug
The stranger test. Design that needs no manual, measured in seconds.
Martin Fowler
How to split the giant file safely, one small step at a time.
Three pages: ten mistakes, the fixes, the 30-second checks, and the bookshelf they come from. I'm applying all of it to my own rebuild, in public.
Download Mistakes 101 (PDF)