The bill for a small live project is usually a few euros a month. The stories you hear about are four figures over a weekend, and they almost never come from a sudden crowd of users.
They come from a loop nobody put a limit on, running at full speed while its author was asleep.
The idea
Your bill has two halves that behave completely differently. The fixed half is what you pay to exist: a server, a database plan, a domain. It is boring, small, and never surprising. The metered half is charged per unit of something your code does: per API call, per gigabyte transferred, per function invocation, per minute of compute. Metered costs have no natural ceiling, because software can repeat an action several thousand times a minute without getting tired.
steady state (0 users) one unbounded retry loop
---------------------- ------------------------
VPS or hosting ~5 EUR/mo unchanged
Postgres 0 (free tier) unchanged
domain ~1 EUR/mo unchanged
AI API calls ~0 1 call/sec for 24h = ~86,000 calls,
each billed per token
-------------------------- ------------------------
~6 EUR / month an invoice you did not plan
egress is its own story, with its own arithmetic:
a 40 MB video on your landing page x 25,000 visits
= ~1 TB leaving your server that month(Indicative figures, checked 2026-08-12. Your providers will differ; the shape is the point.)
How it works
Four sources cover nearly every runaway story from a solo project.
- AI API calls. Every request to Anthropic's or OpenAI's API is billed per token, and a retry loop that fires on failure will happily retry forever. A single feature that calls a model once per page view is fine at ten visitors and is not fine when a crawler finds you.
- Data leaving your server, out to users or to another service. Providers usually charge for data going out and not for data coming in. Serving a large file to many people, or copying between two clouds, is billed per gigabyte. AWS is the well-known example, but most providers meter it above some free allowance.
- Scheduled jobs. A cron job that starts a task before the previous one finished stacks them up. By hour six you have hundreds of overlapping runs, each holding a database connection.
- Unbounded loops. Anything that fetches until a condition that never becomes true, or writes a row on every iteration. This is the one an AI-written feature is most likely to hand you, because the happy path works perfectly in testing with three records.
Watching the dashboard does not fix any of these, because they all run fastest while you are asleep. What fixes them is a ceiling set in the provider's own billing, where your code has no vote. The catch is that most of the controls offered to you are not ceilings. Look for whether the control acts or only speaks (checked 2026-08-12):
| Control | What it does |
|---|---|
| Prepaid credits, auto-reload off | Spending stops when the balance reaches zero |
| A hard spend or usage limit (Anthropic and OpenAI spend limits, Railway's hard limit) | Requests are refused, or workloads taken offline, past the number you set |
| A usage alert or soft limit (Railway email alerts) | Notifies you. Spending continues |
| Vercel Pro spend management | Notifies by default. It only stops anything if you separately switch on pausing, and then several minutes late |
| AWS Budgets, on its own | Sends an email. Charges continue at full speed |
| AWS Budgets with a budget action | Can apply a deny policy or stop instances automatically |
What to do
- Go through that table with your own providers, today, and write down which row each one is in. Anthropic's Console has spend limits per workspace and OpenAI has a hard spend limit that stops API traffic at the number you set. On prepaid credit, turn auto-reload off: with it on, the balance refills itself and the spending carries straight on past the ceiling you thought you set.
- Where the alert is your entire defence, set it low: half of what you would call a bad month, delivered to email and phone. Then set a second one higher. The first tells you something changed, the second that it is still going.
- Ask for limits when you ask for the feature. "Retry at most three times with a delay between attempts, and stop after 100 items" in the prompt is worth more than any review you do afterwards.
Where it breaks
Caps have teeth, and teeth cut both ways. A hard spending limit that trips on a Saturday takes your feature offline until you notice, which for a paid product may be worse than the charge. Decide per service which failure you prefer, and write the choice down next to the number.
Some costs cannot be capped at all. Bandwidth on most hosts is billed after the fact, so by the time the alert reaches you the money is already spent. Cloudflare in front of your origin helps, with a limit worth knowing before you rely on it: it decides what to cache by file extension, so images, fonts, CSS and JavaScript are cached by default and your HTML and API responses go to the origin every time (checked 2026-08-12). That covers the bulk of the bytes on a typical site and none of the dynamic load. Add a cache rule for whatever you actually serve, then read the cache hit rate in the analytics tab a day later.
Free tiers also end in two different ways, and which one you get is not your choice. Supabase and Vercel's Hobby plan stop or throttle at the limit, so your first taste of success arrives as an outage. Railway's free trial ends in a paid plan that bills instead (checked 2026-08-12). Know which of the two your host does before the day it happens.