The surprise bill in a vibe-coded app: what actually drives it up, and a check before you launch

You launch on a Saturday. Someone posts the link on Hacker News or Product Hunt, a few people share it, and by Monday you have real traffic for the first time — more visits in one day than the whole month before. It feels like the best weekend since you started the project. Then the invoice email from your host or your AI provider arrives, and the number on it has nothing to do with how many people actually signed up.

This is the fifth check Rampa Solutions runs before you ship anything built with AI: accessible, secure, private, legal, and no surprise bills. This piece is about that last light specifically, because it is the one almost nobody thinks to check on their own app until the bill has already happened.

Why a good launch and a bad bill are the same event

Most vibe-coded apps run on usage-based pricing by default: you pay per image served, per API call made, per database row read, per function invoked. That pricing model is invisible on a slow day, because there is nothing to add up. It becomes visible the moment traffic shows up, and traffic showing up is the entire point of a launch. Nobody sets a spending limit for a weekend project, because until the traffic arrives, there is nothing to limit.

The three places the number actually comes from

• Images or video that are not cached or resized: every visitor downloads the full-size file straight from your server or your database storage, instead of a small, cached copy served by a CDN. A handful of large photos, multiplied by ten thousand page loads, adds up fast.
• An AI API call (OpenAI, Anthropic, or similar) that runs on page load or on a public action with no cap per user or per day. Ten thousand visitors trying your AI feature once each means ten thousand billed calls, and a script that finds the same endpoint can trigger far more than that.
• A public form — signup, chat, contact, waitlist — with no rate limit and no bot check. Anything that lets a script hit it thousands of times a minute turns every hit into cost: an email sent, a row written, a model called.

None of these three show up in a demo. They only show up under load, which is exactly the moment a builder is not watching the dashboard — they are watching the sign-up count instead.

How to check your own app in five minutes

• Open your site's network tab and look at the size of the images actually being downloaded. If a photo you resized to look small in the browser is still a 3 MB file coming over the wire, it is not cached or resized on the server.
• Find every place your app calls an AI API. Check whether that call runs once per page view, once per user session, or only after a person explicitly clicks something — and whether there is any limit on how many times one visitor can trigger it.
• Check your public forms for a rate limit or a bot check (a captcha, or a simple limit like "no more than five submissions per minute per IP"). If there is none, there is nothing between the form and a script.
• Open your hosting and API provider dashboards and look for a spending alert or a hard budget cap. Most platforms let you set one; most default projects never have one set.

What actually fixes it

• Set a budget alert or a hard spending cap on every provider that bills by usage — your host, your database, and any AI API. An alert at a few dollars over your normal week catches a spike before it becomes a bill.
• Put images and any static file behind a CDN with caching, and move video off your own server entirely — a hosted video platform is built for exactly this kind of traffic and your own server is not.
• Add a per-user or per-IP limit to any AI call the public can trigger without logging in, even a simple one. It is the difference between one visitor costing you one call and one script costing you thousands.
• Add basic rate limiting to public forms. A few lines of middleware is enough to stop a script without adding friction for a real person filling in one form once.

None of this needs to happen before your first user. It needs to happen before your first busy day, because that is the day a small oversight turns into a real number. A passive scan of what you already shipped checks for exactly this — uncached assets, unthrottled endpoints, missing rate limits — alongside the exposed keys, missing labels, and open database it already looks for, without ever needing your login.

Run a free check before your next launch post: https://rampa.solutions/?de=blog-vibe-coded-app-surprise-bill