Builders trade the same disaster stories the way pilots trade weather. One is the surprise bill, where a paid API ends up inside a loop one evening and the meter runs unwatched for days. The other is the leaked key, where a secret lands in a public repository, bots watching for exactly this find it within minutes, and strangers spend on the account. The details change, but the pattern holds: working code, a small operational gap, and a consequence out of proportion to the mistake.
Neither story is about code quality.
A working build does not hurt you because the code is bad. It hurts you because of an operational gap nobody closed before launch.
Closing these gaps takes a handful of operating disciplines that experienced builders carry as reflexes and rarely write down, because each one feels obvious the day after it would have saved you. We write them down here early, so you can run them as a pre-flight on everything you ship and keep these stories secondhand.
Secrets never live in the code
A secret is anything that lets its holder spend your money or read your data: API keys, database passwords, access tokens. Each lives in an environment file, a text file of named values read at runtime, the mechanism from Environments: why it works on your machine and breaks online. That file is listed in .gitignore, the list of files git ignores, so it never enters your project history, and in production the host holds the values instead.
The failure it prevents. A key inside the code travels everywhere the code goes: into git history, then into a public repository the day you share your work. To the provider's billing meter, whoever holds the key is you.
The five-minute version. Ask your coding tool to move every secret into an environment file, add the file to .gitignore, and search the project for anything that still looks like a key.
Keep personal data minimal and know where it sits
Store anything about a real person, a name, an email, a location, an IP address, and you take on obligations that outlast the feature you collected it for. Handle as little as possible and know exactly where it sits: collect only what the product needs, and name where every piece rests, which table, which log, which third-party service, the question from Data, where information lives.
The failure it prevents. Logs and error trackers keep whatever passes through them, and the quiet leak is discovering months later that yours has been storing customer emails. You cannot protect or delete data you cannot locate.
The five-minute version. List every piece of personal data your build touches, write one storage location next to each, and strike anything with no clear job. A piece of data you cannot place is the gap you just found.
Put a hard cap on anything that spends money
Anything in your build that spends money needs an automatic limit: model API calls, hosting, outbound email or SMS. A billing alert tells you spending crossed a line; a hard cap stops it whether or not you are awake. Set both before launch, the alert at a number that would annoy you and the cap at a number that would hurt.
The failure it prevents. A retry loop in your own frontend, or a bot that found your AI endpoint, runs the bill all night, and an alert without a cap wakes you up just to watch it happen.
The five-minute version. Open the billing page of every service that holds your card, set the alert, and add the hard limit wherever one exists, the move you made in Hosting, renting a computer on the internet.
Rate limits are not optional
A rate limit caps how often one caller can hit an endpoint. Every public endpoint gets one, and anything that costs money per use also gets a per-user cap, a daily ceiling per account.
The failure it prevents. Bots probe everything public and will call a metered endpoint thousands of times, and your own frontend can do the same when a bug retries a failing request in a loop. The limit stops both without your attention.
The five-minute version. Most hosts and frameworks ship rate limiting as configuration rather than code. Ask your tool what your stack offers and turn it on, then add a daily per-user cap to every feature that calls a model.
Write down how to turn it all off
Before anything reaches real users, write down how you would turn the whole thing off in about two minutes, usually a maintenance setting the deployment reads or the host's control for taking the deployment offline. The discipline is knowing which is yours and where the steps are written.
The failure it prevents. Something misbehaves in front of users or spends in a loop at 2 a.m. while you read documentation for the first time, and the incident you could have ended in two minutes runs for an hour.
The five-minute version. Write the steps into the project README and use the switch once, deliberately, before launch, so the first real use is not the first rehearsal.
Extra rules when an agent does the work
The disciplines above assume the mistakes are yours. An agent puts the same money, data, and access in play faster than you can read along.
Checkpoint before the agent works. A save point exists before the agent touches anything, the reflex from Git: the undo that makes AI edits safe, so the worst case for your files is restoring and retrying.
Least permission. Give the agent the narrowest access that does the job: development keys rather than production ones, a test database rather than the live one. An agent cannot leak or spend a key it was never given.
Never let an experiment touch production data. Experiments run against copies and test records, with the boundary enforced by what the agent can reach rather than by the prompt. The Replit incident from the git chapter, an agent deleting a live production database despite explicit instructions, is the standing reminder that phrasing is not access control.
What we run on this site
Here is the whole pre-flight on one card. The first run takes an hour, and every run after takes minutes.
Against this site, the list comes back short.
- Secrets. Every key lives in environment variables held at the host, and the repository contains writing and code, nothing that spends.
- Personal data. We collect none. No accounts, no stored emails, nothing to leak.
- Money. Spend alerts are set on every account that holds our card.
- Rate limits and the off switch. Cheap for us, since nothing here bills per use and taking the deployment offline is a standard hosting control. A build with users and metered model calls earns both the hard way.
The list does not need to be all green to ship. It needs honest answers, and the yellows and reds become your pre-launch to-do list.
Try it now
No setup: Run the pre-flight on paper against the build you chose in Find your build and pick its shape, before any of it exists, and mark each discipline green, yellow, or red with one sentence each. Red is a fine answer this early, because each answer is a decision you would otherwise meet the night before launch.
With your tools: Open Claude Code in your project folder and ask: "Where would secrets live in this project? Create the environment file if there is none, add it to .gitignore, and search the code for anything that looks like a real key." In Codex or Cursor the move is the same: ask the sidebar chat where secrets live and whether the environment file is ignored by git. If your tools are not set up yet, The Setup Clinic gets you there in one sitting.
Chapter Summary
- A working build hurts you through operational gaps, not bad code. The pre-flight is the short list of disciplines that close those gaps before launch.
- Keep secrets out of your code. They live in an environment file that git ignores, and the host holds the real values in production.
- A secret that ever touched a shared or public repository is leaked. Revoke it at the provider and issue a fresh one.
- Collect as little personal data as you can, and be able to name where every piece of it lives.
- Put both a billing alert and a hard cap on anything that spends money, so a runaway loop stops whether or not you are awake.
- Give every public or metered endpoint a rate limit and a daily per-user cap, so bots and buggy retries cannot run up the bill.
- Write down how to turn the whole thing off in about two minutes, and rehearse that switch once before real users arrive, so the first real use is not the first try.
- When an agent does the work, add a save point before it starts, give it the narrowest access that does the job, and keep experiments away from real production data.
- This checklist covers what your build could do to you. Next, The legal basics every public build needs covers what shipping to the public obliges you to do.
Sources
- Business Insider and Fortune reporting on the Replit coding agent incident (2025).