Vibe coding — describing what you want in plain English and letting an AI write the code — is genuinely good at one thing: getting an idea from nothing to something that runs. A working login screen, a dashboard, a checkout flow, in an afternoon instead of a sprint. That part is real, and we're not here to talk you out of it.
What it doesn't tell you is that "it works on my screen" and "it works" are different claims. We see the gap constantly in vibe-coding cleanup work — the app runs perfectly for the person who built it, then falls over in ways nobody demoed for. Here's specifically what breaks, and why.
Authentication that only handles the happy path
Vibe-coded auth almost always covers sign-up and sign-in — because that's what you asked for, and it's what shows well in a demo. What it quietly skips: session expiry, password reset flows that don't leak whether an email exists, rate limiting on login attempts, and authorisation checks on every route that touches user data, not just the ones with a visible "login required" wall. We regularly find API endpoints that are one URL guess away from any user reading any other user's data, because the AI wired up the button that calls the endpoint and never asked whether the endpoint itself checks who's asking.
Error handling that assumes nothing ever goes wrong
A prototype's happy path always works, because that's the path you tested. Real usage isn't a happy path — it's a payment gateway timing out mid-checkout, a file upload that's 40MB instead of 4, a user who double-clicks submit, an API you depend on returning a 500 at the worst possible moment. Vibe-coded apps tend to handle none of this gracefully: the error either crashes the page, silently does nothing, or — worse — half-completes an action and leaves the data in a state nobody accounted for.
Data validation that trusts the client
If the AI wrote both the form and the API behind it, it's easy to end up validating input only in the browser — client-side checks that a form field is required, with nothing stopping the same request being sent directly, unchecked, from anywhere else. Every input from outside your server needs to be validated on the server, every time, regardless of what the front end already checked. This is the single most common gap we find, and the most dangerous one, because it's invisible until someone (or something automated) sends a request the UI was never designed to send.
Cost and scale nobody modelled
An AI coding assistant optimises for "does this work," not "what does this cost at 10,000 users." We've seen vibe-coded features that call an LLM API on every keystroke, database queries that scan an entire table because there's no index, and image processing that runs synchronously in the request path instead of a background job. None of it shows up in a demo with one user. All of it shows up in the first invoice, or the first slow page complaint, after real traffic arrives.
Security gaps nobody thought to ask about
Secrets committed straight into the repository. CORS set to allow any origin because it made local testing easier and nobody changed it back. SQL built with string concatenation instead of parameterised queries. None of these are exotic mistakes — they're the default outcome of asking an AI to make something work, without a second pass asking whether it's safe. The AI answered the question you asked. Security is rarely the question anyone asks first.
What "cleanup" actually means
Not a rewrite — that throws away the genuinely good work of getting the idea proven. Cleanup means going through the app with a production checklist: authorisation on every route, server-side validation on every input, error handling that fails safely instead of silently, secrets moved out of the code, obvious cost and performance traps fixed before they're expensive, and enough logging that when something does break in production, you find out from a dashboard instead of a customer.
How to tell if yours needs it
If the app was built primarily by describing what you wanted to an AI, if nobody has specifically reviewed authentication and authorisation as their own task, and if it's about to meet real users, real payments or real customer data for the first time — it needs a pass before it does. That's true whether the app is going live next week or has quietly been live for months on the strength of "it hasn't broken yet."
The prototype did its job — it proved the idea was worth building. We do the pass that makes it safe to actually run, or if you're not sure yet which parts of yours need it, tell us what you built and we'll tell you honestly what we'd fix first.