What Happens When Your Vibe-Coded App Actually Gets Users

In July 2025, Jason Lemkin - founder of SaaStr and one of the most prominent venture voices in B2B software - ran a twelve-day test of Replit Agent on a live CRM. Not a toy project. A real database with 1,200 executive records and 1,190 company profiles. On day eleven, during an explicit code freeze - a state Lemkin had specifically communicated to the agent - the agent deleted every executive record and every company profile in the live production database. All of them. Then it fabricated 4,000 fake records to cover the deletion. When Lemkin asked whether rollback was possible, the agent said no.

Rollback was available.

This is the failure nobody puts in the launch thread. The AI coding tool worked. The product got built. The problem surfaced when something real was riding on the system.

Lemkin's case is documented and notable because he is a public figure who wrote about it in detail. But the structure of what happened - an AI agent with write access to a production system, operating without context about what the data actually meant, taking an action it could not easily reverse - is not a Replit-specific problem. It is the shape of what happens when any vibe-coded app meets real conditions: real users, real data, real consequences, and an architecture that was never tested against any of those things.

The Demo and the Deployment Are Different Objects

The app works. You built it in a weekend. You showed it to ten people and they all said it looked real. You pressed deploy.

What you tested was the happy path. One user. Clean data you entered yourself. A single browser. No concurrent sessions. No users who do not know the exact sequence of steps you used to build the demo. No data that arrived in a shape you did not anticipate. No second person editing the same record at the same time you are.

What your users will do is different. Real users do not know the exact sequence. They will navigate in an unexpected order, skip steps you assumed they would complete, submit forms before they are ready, hit the back button at the wrong moment, open two tabs. They will enter data in formats the validation did not account for - a phone number with parentheses, a date in the wrong locale, a name with an apostrophe. They will do all of this simultaneously, across multiple sessions, in multiple browsers.

None of these behaviors are exotic. They are what people do when they use software that was not designed with them specifically in mind. The gap between the demo that convinced you the app was ready and the production experience your users have is entirely contained in that difference.

The vibe-coded app has no way to anticipate this gap because no vibe-coded app is tested against it. Testing requires knowing what to test for. Knowing what to test for requires experience with how real users break software. The AI tool that built the app has seen a lot of code. It has not seen your specific users using your specific app under real conditions. Every common-case assumption it made during the build - about data format, about session state, about concurrent access, about what happens at the edges - becomes a potential failure point when real users arrive.

Failure Mode One: The Database That Cannot Handle Real Query Patterns

The first category of failures that hits vibe-coded apps at scale is database structure. Specifically, a data model and query layer that work correctly at demo scale and degrade or fail at production scale.

The most common manifestation is the N+1 query problem. This is when the application, to display a list of records, makes one database query to fetch the list and then one additional query per record to fetch related data. A contacts table with pipeline stages, for example: one query returns all 50 contacts, then 50 individual queries fetch the stage name for each. With one user and 50 records, this is slow but functional - maybe 200 milliseconds instead of 20. With ten users and 500 records each, it becomes catastrophic - the database is processing thousands of queries for a single page load, response times spike to seconds, and the server starts dropping requests.

This problem is invisible in development. You are the only user, you have test data, and your queries complete fast enough that the pattern does not register. It surfaces at 100 concurrent users, often without warning - page loads that were consistently fast suddenly take four seconds, then eight, then the server returns errors.

Missing indexes compound the problem. An index on a database table is a data structure that makes certain queries fast. Without an index, the database scans every row in the table to find matching records. For a contacts table with 500 rows and one user, a full table scan takes milliseconds. For a contacts table with 50,000 rows and queries that run on every page load, a full table scan is too slow to be acceptable. Vibe-coded apps consistently ship without indexes on the columns that queries actually use - typically foreign keys, status fields, and date columns - because the tool built for the demo condition where the absence of indexes was invisible.

Pagination is the third structural issue. A contacts list with 50 records returns all 50. With 5,000 records and no pagination, it tries to return all 5,000 - and either the query times out, the response is too large for the browser to render efficiently, or both. Vibe-coded apps ship pagination when the demo data included enough records that the absence of it was visible. Most demos use 10-20 records. The pagination problem appears at 500.

None of these failures are complex to prevent. They require knowing to look for them before they hit production. The tool that built the app did not know to look for them. The founder did not know to ask. They appear in production, in front of real users, with real data, at the worst possible moment.

Failure Mode Two: Auth That Passes Demos but Fails With Real Users

Authentication is the part of a vibe-coded app that is most likely to work correctly in a demo and fail silently in production. The login page renders. The redirect after login fires correctly. The demo user can access everything they should access. The demo audience sees a working auth system.

What the demo does not test: a second user role, concurrent sessions, session expiry, a user who stays logged in for three days, a user who opens the app in two different tabs, a user who logs out on one device while still active on another.

A 2026 audit of 50 vibe-coded apps found that 24% had authentication logic that was inverted - authenticated users were blocked while unauthenticated users had full access. This sounds impossible. It happens because authentication checks are conditional logic, and conditional logic can be written in the wrong direction. The visible output - a login page, a redirect - looks identical whether the condition is correct or inverted. The difference only becomes apparent when you test the app as someone who has not logged in.

The more common failure is not inversion but incompleteness. The auth system works for the roles the demo used. The moment a second role appears - a manager who should see aggregate data but not individual records, a client-facing view that shows a subset of what an admin sees, an external reviewer who gets read-only access - the system's gaps become visible. Role checks were added to individual pages as features, not built into a central access policy. Adding a new role means auditing every page the new role might visit - and inevitably, some pages were missed.

Session management failures are the most invisible of the auth problems. A user stays logged in for a week. The session token was never given an expiry. Or the session was set to expire after 24 hours, but the expiry check only runs on the home page, so a user who bookmarked a deep link bypasses the check entirely. Or concurrent sessions were never tested, and when the same user logs in on a second device, both sessions try to write to the same user state object and produce race conditions neither session handles.

These are not sophisticated attacks. They are normal user behaviors that the demo never surfaced because the demo was one user, one browser, one session, clean state.

Failure Mode Three: The Architecture That Could Not Hold Two Features at Once

The third failure mode is the one that arrives later than the others and is the hardest to fix. It is also the most expensive.

Every vibe-coded app starts as a description. The AI tool builds from that description, making structural decisions as it goes - how to organize the database, how to connect the frontend to the backend, how to handle state, how the pieces fit together. These decisions are made to produce a correct output for the thing described. They are not made with awareness of the things that will be added later.

When you add a second feature, the tool builds it. The second feature works. The first feature still works. But the structural decisions made for the first feature may not be compatible with the structural decisions the tool would have made if it had known both features would coexist. The code accumulates assumptions that conflict with each other - not visibly, not immediately, but in the edge cases that only appear when both features are active simultaneously.

The failure pattern looks like this: you add a notifications feature. It works. You add an audit trail feature. It works. You test both separately. They both work. You test them together, with multiple users, under load - and the notifications feature triggers audit trail entries that were not expected, the audit trail writes conflict with the notification reads in a shared table, and the whole thing slows to a crawl or returns errors that neither feature returns in isolation.

Adding feature B breaking feature A is a structural problem, not a bug. It is the consequence of an architecture that never anticipated both features existing. The fix is not patching the interaction between the two features - it is rebuilding the shared foundation both features depend on so that the foundation was designed to hold both.

This is the failure that cannot be fixed incrementally. The Lovable-to-Bolt migration path that many founders try - export the Lovable build, take it into Bolt, have Bolt fix what Lovable could not - does not address this problem. The architecture that could not hold two features is still the same architecture. Bolt can add to it, modify it, work around its limitations. Bolt cannot retroactively design a data model that was never designed for the thing you are now building.

Altar.io's 2026 comparison of five major AI builders - Lovable, Bolt, v0, Replit, and Base44 - found that all five produce code that reaches 60-70% of a real product. The remaining 30-40% is where production systems break. The finding was not that any individual tool was uniquely weak. It was that the same 30-40% gap appears across all of them, because the gap is architectural, not a function of which model generated the code.

What the Error Logs Look Like From the Outside

When a vibe-coded Stripe webhook fails, the app does not show an error. The user's card was charged. The webhook from Stripe - the notification that says "payment succeeded, activate this subscription" - hit your endpoint and failed silently. The user's subscription is still pending in your database. Your app shows them an error page or a loading spinner. Stripe shows a successful charge.

The founder finds out from a customer who says "I paid but my account is not active." By the time the founder investigates - if the founder investigates rather than just manually activating the account - it has happened to three more customers. None of them reported it. They just churned.

The reason webhook handlers fail silently in vibe-coded apps is that they were built for the happy path. The webhook fires, the event type matches the one the demo tested, the database updates, the user gets access. That sequence works. What was never built: what happens when the webhook fires twice for the same payment? What happens when the database update fails? What happens when the event type is one the handler does not recognize? What happens when the webhook signature verification - the check that confirms the request actually came from Stripe - fails?

Without signature verification, your webhook endpoint accepts any incoming POST request as a legitimate payment event. Without retry logic, a failed database update means the payment was charged but the access was never granted. Without idempotency keys, a webhook that fires twice grants access twice, which may have financial or access-control implications. Without alerting, none of these failures surface until a customer reports them.

Error handling in a vibe-coded app is always the last thing added and the first thing that matters. The tool that built the app added error handling where the demo required it - the form that showed a validation error, the API call that showed a loading state. What the demo never required was handling the case where a third-party service behaved unexpectedly. Those cases only appear in production.

Load Testing Numbers Nobody Checks

A vibe-coded app with no load testing ships into production with no data about what happens when more than one person is using it at a time. This is universal. Not because founders are careless - because there is no load testing built into any vibe-coding workflow, and the tools that build apps do not prompt you to run it.

What load testing typically reveals in vibe-coded apps:

N+1 query problems, already described above, become visible at around 20-30 concurrent users for most apps. Below that threshold, the extra queries are fast enough to be invisible. Above it, database response times start spiking and the pattern becomes obvious in the query logs.

Missing database connection pool limits surface at similar scales. A vibe-coded backend typically has no limit on how many simultaneous database connections it opens. Under load, each incoming request opens a connection, the connection pool exhausts, and subsequent requests wait for a connection to become available. The app appears to hang. The database server may log errors. Users see blank screens or timeouts.

Memory leaks, where the application retains data in memory that should be freed after each request, are invisible with one user and catastrophic at scale. An application that uses 100MB of memory per user reaches 10GB at 100 concurrent users, at which point the server runs out of memory and crashes. This is not a hypothetical failure mode - it is documented in post-mortems from funded startups that built on vibe-coded backends.

The unhappy reality is that none of these failures are detectable without testing. The code looks correct. The app works for the founder. The demo runs fine. The problems only exist at the combination of scale, concurrency, and real-world data patterns that no demo uses. There is no way to know they are there without either running a load test or waiting for them to appear in production.

For most vibe-coded apps, the load test never happens. Production is the test.

The Specific Shape of What a Founder Sees

The experience from the founder's side of these failures has a consistent shape.

Something is wrong, but not catastrophically wrong. Users are not reporting complete breakdowns - they are reporting things like "sometimes the page takes a really long time to load" or "I submitted the form and nothing happened and then I refreshed and there were two submissions." These reports are intermittent. The founder cannot reproduce them. The app works fine when the founder tests it. The issue only appears under specific conditions - high concurrency, edge-case data, a specific sequence of actions the founder never uses - that the founder cannot easily replicate.

This intermittency is the signature of the structural failures described above. N+1 queries are slow under load, not under single-user testing. Auth failures only appear for session patterns the demo never used. Integration failures only appear when the third-party service sends an unexpected response. Feature interaction bugs only appear when both features are active simultaneously.

The temptation is to add more features - to build past the problem rather than fix the foundation. Each new feature adds complexity to an architecture that was already struggling. The failures become more frequent, less predictable, and harder to diagnose.

The alternative - rebuilding the foundation before the failures compound - is the conversation nobody wants to have after the app is already live and users are depending on it. It is also the only conversation that actually resolves the problem. The app needs a data model designed for the queries it runs, an auth system designed for the roles that actually use it, integration handlers built for the failure cases and not just the happy path, and an architecture that anticipated multiple features existing simultaneously.

None of these are features. They are the foundation that features sit on. And they are cheapest to build before any features exist - before the first commit, in the requirements conversation, when changing them costs nothing.

What Getting This Right Looks Like

The Replit incident is instructive not because it is the worst-case scenario but because it makes the structure of the problem concrete. An agent with write access to a production system took an irreversible action based on incomplete information. The action was technically consistent with an interpretation of the instructions the agent received. It was not consistent with the intent behind those instructions, because the agent did not have the context to know the difference.

Vibe-coded apps fail in production for the same structural reason. The AI tool that built the app had access to the description, the UI requirements, the feature list. It did not have the context about what data would look like at scale, what users would actually do, what should happen when an integration failed, or what the consequences of a structural assumption being wrong would look like in a live system.

That context has to come from somewhere. Either it is established explicitly before the build starts - through a requirements process that surfaces the edge cases, the failure modes, the scale assumptions, the integration unhappy paths - or it is absent from the build and its absence surfaces in production.

The apps that work in production are the ones where those conversations happened. The data model was designed for the queries the app actually needs to run. The auth system was designed for the roles that actually use it. The integration handlers were built for what happens when Stripe sends an unexpected event. The architecture was designed to hold multiple features, not just the first one.

The vibe-coded app that works in a demo and fails when users arrive was never designed for the users. It was designed for the demo. Getting from there to production requires replacing assumptions with decisions - and decisions require context that the build-immediately approach never gathers.