A founder emailed us last month with a screenshot of a Vercel invoice that had gone from $20 to $1,400 in a single billing cycle. The app hadn’t grown much. User numbers were flat. Nothing in the product had visibly changed. What had changed was buried three layers down in the code, in a pattern the AI tool had written without anyone asking it to. A high cloud bill rarely comes from success. Most of the time it comes from code that never learned to be careful with resources, and nobody was watching closely enough to notice until the invoice arrived.
We see this constantly in AI-generated codebases. The app works. It even feels fast in testing. Then real usage kicks in and the hosting bill starts climbing in a way that has nothing to do with revenue.
How a small app runs up a big bill
Here’s the thing that surprises people: it doesn’t take much traffic to generate a large bill if the underlying code is inefficient. A hundred users a day is nothing. But if each of those users triggers ten unnecessary function calls, three redundant database round trips, and a couple of calls to a paid API that didn’t need to run, you’re not looking at a hundred billable events. You’re looking at thousands, every single day, compounding for weeks before anyone checks the dashboard.
AI coding tools optimise for “does this work” not “does this work efficiently.” They will happily generate a serverless function that queries the database five times to render one page, because each individual query works fine on its own. Nobody told the model that five queries cost five times more than one, and the model has no reason to care. It’s not measuring your bill. You are, later, when it’s too late to un-spend the money.
We’ve written before about the real cost of “free” AI-generated code, and hosting spend is one of the clearest examples. The code was free to generate. It is not free to run.
The usual culprits
A handful of patterns show up again and again when we go through a client’s codebase looking for the leak.
Serverless functions called inside loops are the most common one. A function that processes a list of twenty items might invoke a separate serverless call for each item instead of batching them, and every one of those calls has its own cold start, its own execution time, and its own price tag. On a platform that bills per invocation and per millisecond, a loop like this can quietly 20x your compute costs without a single extra user visiting the site.
Polling instead of events is another big one. We’ve reviewed apps where the frontend checks the server every two seconds to see “has anything changed yet,” even when nothing changes for hours at a time. Multiply that by every open browser tab and you get a steady drip of billable requests that serve no purpose except keeping a loop alive. A websocket connection or a simple event-driven update would do the same job for a fraction of the cost.
Unoptimised images sit quietly in the background racking up bandwidth charges. AI tools frequently skip image compression, resizing, and modern formats entirely, so a product photo that should be 40KB ships at 4MB. That gets served on every page load, to every visitor, from every region, and bandwidth is billed. This is closely related to the performance issues we cover in why your Lovable app is slow and how to fix it, because the same bloated assets that slow your site down are also the ones inflating your transfer costs.
Chatty database queries are the fourth pattern, and probably the one we see most. Instead of one query that joins the data it needs, the code fetches a list, then loops through it firing a separate query for each row. This is the classic N+1 problem, and it’s everywhere in AI-generated backends because it’s the most obvious way to write the logic, not the most efficient one. On a serverless database that bills per query or per compute-second, this pattern alone can dominate your bill.
Finally, paid third-party APIs get called far more often than they need to be. We’ve seen apps that hit an AI API, a geocoding service, or an email verification tool on every single page load, including for logged-out visitors just browsing, when caching the result for even an hour would have cut the call volume by 90 percent.
How to read your bill to find the leak
Most hosting dashboards break spend down by service, and that breakdown is where you start. Look at which line item grew the fastest relative to your traffic. If your visitor count is flat but your function invocation count tripled, that points straight at a loop or a polling pattern. If bandwidth is the outlier, it’s almost always images or uncached static assets. If it’s database compute or read units, you’re looking at query patterns.
Vercel, Netlify, Supabase and most serverless database providers all give you per-function or per-query breakdowns if you dig into the usage tab rather than just the top-line invoice. That’s the page that actually tells you something. The invoice tells you what happened. The usage tab tells you why.
If you genuinely can’t make sense of the numbers, that’s normal, this is exactly the kind of thing we’ve walked founders through before, and it’s covered in more general terms in how much it costs to fix a vibe-coded app, where hosting waste is often part of the total.
The cheap fixes that usually cut it hardest
The good news is that the fixes are rarely expensive to build. Batching database queries into one call instead of a loop is often a small, contained change. Adding a cache layer in front of a chatty API, even a basic in-memory cache with a short expiry, can cut call volume dramatically for almost no engineering effort. Compressing and resizing images, or switching to a modern format like WebP, is usually a configuration change rather than a rewrite. Replacing a polling loop with a webhook or a websocket takes more work but pays for itself fast if polling is your biggest line item.
None of this requires a rebuild. It requires someone who knows where AI-generated code tends to cut corners, and enough time to trace your specific bill back to your specific code.
Bill climbing and you can’t see why? We’ll trace it. Get a free assessment and we’ll show you exactly what’s driving the cost.