What do you check before shipping a vibe-coded site?

by•

I recently designed and vibe coded my portfolio. It has an animated intro, project pages, and a guestbook built with React and Firebase.

The site works, but “it loads on my laptop” is a low bar. If you’ve shipped a vibe-coded website, what did you catch in your final review that you missed while building?

I’m deciding how to review mine and would rather learn from real mistakes than follow a huge generic checklist.

30 views

Add a comment

Replies

Best

Revert the fix and run the test again. An agent wrote what looked like a clean patch with a passing test, but pulling the patch back out left the test green. The assertion was never exercising the bug in the first place.

 That’s a useful check. I’ll make sure a test fails on the broken version before trusting it after the fix.

 When the same model writes both the implementation and the test, circular assertions become the default failure mode. The only real check is seeing it fail first.

Check the guestbook's Firebase security rules first. Vibe-coded apps often ship with the database open, so anyone can read, edit or delete every entry straight from the browser console, without touching your UI. Try it from a logged-out browser. I enforce the same thing in Supabase with row level security.

 Good catch. I haven’t tested the guestbook against Firebase from a logged-out browser yet. I’ll check whether someone can read, edit, or delete entries directly, then tighten the rules where needed. Thanks for the heads-up.

A few things that are rules in every project of mine now, most of them because something went wrong once:

Login gets rate limiting, counted by both account and IP, locked after 5 tries with the wait getting longer each time.

Images get resized in the browser before upload, not left to the server.

No secrets in the code.

Error reporting only fires in production.

And before anything ships, the agent has to open the real page and check it, not just get a clean build.