Suzanne Chartier

Two of mine: "Never edit requirements.txt by hand, it's generated with hashes." Added after an unpinned dependency jumped to a new version on deploy and caused an incident in production. "Any API change updates the docs, the MCP tool descriptions and the slash commands in the same step." Added after an audit against production found the three had drifted apart. Curious what's in yours, and what happened before you wrote it.

I build solo, with coding agents doing most of the typing. Going through this week's threads here, I noticed the bugs that cost me the most had one thing in common: nothing crashed, nothing logged, and no user would ever have reported them.

1. Tests that couldn't see the risk. My API's pytest suite runs on SQLite, which has no Postgres row-level security or triggers. Green every time. Now I check RLS by hand with psql, as anon and as a logged-in user, inside BEGIN...ROLLBACK.

AI can get me to a working app in a day, but "it works on my machine" and "it's safe for real users" are very different things.

The part that worries me is the boring stuff that's easy to miss when the code looks clean and everything runs: API keys sitting in the frontend, auth checks that exist on the page but not on the endpoint, database rules left wide open from the prototype stage, no rate limits on anything. The AI rarely warns you about these unless you ask, and by the time you think to ask, you've already moved on to the next feature.

Right now my pre-launch process is mostly manual and a bit random: I skim through the auth flow, search the repo for hardcoded secrets, and try to break things as a logged-out user. It catches some things, but I never feel fully confident.

I'd love to hear how others handle it: