A small live project costs roughly the price of a coffee per month. A small live project with one bug in it can cost four figures in a weekend, and you will find out on the invoice.

Both of those are ordinary outcomes for the same project. What separates them is usually a loop nobody put a limit on, and almost never a sudden crowd of users.

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, it is small, and it does not surprise you. 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.

code
  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
  Claude API         ~0               1 call/sec, 24h = ~86,000 calls
  bandwidth out      ~0               86,000 x 40 MB  = ~3.4 TB egress
  --------------------------          ------------------------
  ~6 EUR / month                      an invoice you did not plan

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.
  • 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 will stack 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 that 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 hard ceiling set in the provider's own billing, where your code has no vote.

What to do

  1. Set spending caps in every dashboard that offers one, today. Anthropic's console has monthly usage limits, OpenAI has a hard cap, AWS has Budgets, Vercel and Railway both have usage alerts. Set the number to something that would annoy you rather than something that would end you.
  2. Set a billing alert at half your cap, delivered to email and phone. A cap prevents the disaster; the alert is how you find out on day one instead of day thirty.
  3. 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 is the usual answer, since cached responses never touch your server or your bill.

And the free tier is a cliff rather than a slope. Supabase, Vercel and Railway free plans stop or throttle at the limit instead of charging you, so your first taste of success arrives as an outage.