Costs That Run Away While You Sleep
Pay-Per-Use Has No Ceiling
Most services behind a modern app charge by usage rather than a flat monthly fee. AI calls, emails sent, data stored, requests served. During building this is delightfully cheap, which quietly trains you to stop thinking about it. But usage-based pricing has no natural upper bound. If something runs in a loop, or a page reloads repeatedly, or someone discovers your form and hammers it, the bill grows at machine speed. It does not stop for the night. The characteristic feature of this problem is that it happens while you are asleep, and the first notification is the invoice. Nothing about your app will feel different while it is happening.
- Usage-based pricing has no ceiling unless you create one
- Cheap during building trains you to ignore it entirely
- Loops, retries and traffic spikes grow bills at machine speed
- The first sign is usually the invoice, not anything in the app
Set the Caps First
Before you share your link, go into every service you use and set spending limits and alerts. Set a hard cap you can genuinely afford to lose, and an alert well below it. If a service will not let you cap spending, set the lowest alert available and check it regularly. Do this at the start, not when it becomes relevant. By the time it becomes relevant, it is already too late to act. Also make sure the alerts go somewhere you actually read — an address you check on a weekend, not a notification buried in a dashboard. A cap you set in ten minutes is the difference between a strange week and a genuinely painful bill.
- Set a hard cap and a lower alert on every paid service before sharing anything
- Choose a cap you could afford to lose entirely, not one you hope not to hit
- Send alerts somewhere you read at weekends
- Do this before it matters — afterwards is too late to be useful
The Ways Bills Actually Explode
A few patterns cause most of the damage, and knowing them helps you spot the risk in your own project. Something that calls itself repeatedly, so one action becomes thousands. Retries on failure with no limit, so a broken service is called forever. A page that refreshes and re-requests on a timer, left open in a tab for a week. AI features with no limit per user, discovered by someone who finds it entertaining. And a public form with nothing to stop automated submissions. Each of these is fine at your scale during testing. None of them is fine when your link is on the internet unattended.
- Runaway loops and unlimited retries turn one action into thousands
- Auto-refreshing pages left open cost money for days
- Unlimited AI use per person is an invitation once the link is public
- Public forms need something to stop automated submissions
Prefer slides, quizzes, and saved progress? Read this lesson in the library — free, no sign-up.