Where did the breakdown happen first when your vibe-app met actual people?
by•
The booking app was perfect for me and two testing friends. Then forty users registered within an hour, and everything started to crawl.
What made it slow was the query that the AI created loading all bookings on each page view. It happened because it seemed so fast during the demo and I haven’t thought about anything more. The addition of the index and pagination fixed this issue within twenty minutes, but it cost me half a day to find what makes it slow.
It is really interesting to share our experience about finding problems in the code. So, tell me about the first issue that appeared in your project and how you’ve discovered it.
6 views
Replies
Same shape on my side, but it showed up as a bill instead of a slow page. A monitor in my Polymarket bot re-downloaded the last 200 large trades, uncompressed, every 20 seconds, just to find zero or one new one. That added up to 8.6 GB of proxy traffic before I noticed. Gzip, pages of 20 and a 60-second poll cut it about 100x, and pagination still walks back to the last seen trade so nothing gets skipped.
Twenty minutes to fix and half a day to find is the usual ratio for this one. While that query is fresh, it's worth checking what the "load all bookings" response actually contained. When an AI-written page fetches every booking and filters in the browser, the full list often goes to every visitor, names, emails and phone numbers included, and the page simply hides the ones that aren't theirs. Pagination fixes the speed but not that. Quick check: log in as a test user, open devtools on the bookings page, and look at the raw network response for any other customer's details. Then replay the same request logged out. Did your fix move the filtering to the server, or does the query still return everyone's bookings, just in pages of twenty?