Here’s an uncomfortable question to ask about your app before you launch it: when something breaks for a real user at 2am, how do you find out? For a lot of vibe-coded apps the honest answer is “the user emails me, eventually, if they bother.” Error handling and logging are the unglamorous parts an AI rarely builds well on its own — and they’re the difference between a quiet fix and a silent, ongoing failure.
Two failure modes, both common
AI-generated apps tend to land in one of two bad states:
- Leaking. An unhandled error dumps a raw stack trace to the user — file paths, query fragments, library versions, sometimes secrets. It looks unprofessional and it hands an attacker a free map of your internals.
- Silence. Errors are caught and swallowed —
catch (e) {}— or logged to a console nobody reads. The request fails, the user sees a blank or a spinner, and nothing anywhere records that it happened.
Both pass the demo. In the demo nothing goes wrong.
Why it matters more than it looks
You can’t fix what you can’t see. An app with no logging and no error tracking is one where bugs accumulate in the dark — a payment that silently fails, a feature that errors for everyone on Safari, a job that’s been dying for a week. You find out from churn, not from a dashboard. And the leaking version is an active security problem: detailed errors are reconnaissance.
The minimum to have before launch
- Catch and handle. Show the user a clean, generic message; keep the details server-side.
- Log the details somewhere real. Not
console.loginto the void — a logging service or at least persistent server logs you actually look at. - Add an error tracker. A Sentry-style tool that captures exceptions with context and alerts you. This is the single highest-leverage thing on the list.
- Alert on the things that matter. A failed payment or a spike in 500s should reach you, not wait to be discovered.
- Validate input so predictable bad data is a clean rejection, not an exception (the same trust problem behind data-leak bugs).
How to check
Send your app a deliberately bad request — a malformed body, a missing field, a wrong type. What does the user see? If it’s a stack trace, you’re leaking. What got logged, and would you have noticed? If the answer is “nothing” and “no,” you’re flying blind.
Observability is easy to skip because the app works without it — right up until it doesn’t, and you can’t tell. A seniorgrade audit flags where errors leak, where they’re swallowed, and what you’d be blind to in production. The free self-check includes it in the pre-launch read.