On this page
Every one of these was added on purpose, to unblock something, and it worked. That is why they survive: nothing breaks afterwards to remind you. A permissive rule added at 1am to get past an error is indistinguishable, the next morning, from a decision.
Seven things, each of which has been found on something already live.
The seven
| # | Switch | Why it is still on |
|---|---|---|
| 1 | Test accounts | you log in with one daily |
| 2 | Seeded demo data | it made the empty state look finished |
| 3 | Debug or health endpoint | you needed it once, it never broke |
| 4 | Permissive access rules | added to get past an error, then forgotten |
| 5 | Payment provider in test mode | real payments were not the thing being tested |
| 6 | Verbose errors | they were how you debugged |
| 7 | Email sender pointing at you | you were the only recipient |
Four and five are the expensive ones. Six is the embarrassing one.
Why is a test account worse than a weak user password?
Because of what you gave it.
Test accounts exist to make development fast, so they tend to collect permissions — admin rights, skipped verification, access to every record. They also tend to have a password you can type quickly, which is the opposite of what their privileges deserve.
The result is the most powerful account on the system protected by the least effort. Delete them before launch rather than changing the passwords; a disabled account cannot be re-enabled by accident.
What is wrong with leaving the demo data?
It is the difference between a product and a prototype, and your visitors can tell.
Seeded records make an empty application look alive while you build it, which is genuinely useful. Left in, they say something you did not intend: that the activity is fake, and therefore that the numbers elsewhere might be too.
Worse, people interact with it. Someone will reply to a seeded message, or buy a demo product, and now the fake data is entangled with real data.
The whole list
67 tools, what each costs and when you actually need it. Updated twice a year.
How do you catch the payment one?
Buy something yourself with a real card, then refund it.
Test mode is specifically designed to be invisible — the flow completes, the receipt appears, the dashboard shows a payment. The only difference is that no money moved, which is not something the interface tells you while you are looking at it.
One real purchase exercises the entire chain at once: the card, the webhook, the file delivery, the receipt email, and the thank-you page. It costs the card fee and finds more than any amount of reading. What taking your first payment online actually costs has what that fee is.
Why do verbose errors matter?
Because a stack trace is a description of your system, written by your system, handed to whoever asked.
Framework, version, file paths, sometimes the shape of a query — all useful to you, all useful to someone probing. None of it needs to reach the visitor to reach you.
Log the detail somewhere you can read it, show a sentence to the person. On a free hosting tier, check how long those logs are kept before relying on them; free hosting until it is not covers the retention limits that make this awkward.
And the permissive rule?
This is the one that actually loses data, and it is hard to find because it looks deliberate.
The pattern: something failed with a permissions error at an inconvenient hour, you widened the rule to see whether that was the cause, it was, and you moved on. The code works. There is nothing to notice.
The only reliable defence is to look rather than to remember: read your access rules once, top to bottom, immediately before launch, and ask of each one whether you would write it that way today. Ten minutes, and it is the single highest-value item on this page.
When should the check happen?
The day before, not the morning of.
Items four, five and seven take longer to fix than to find. Discovering a permissive rule an hour before you announce something means either a delayed launch or a shrug, and nobody has ever chosen the first one at that point.
What a stranger can read from your app is the complementary check from the outside, and test accounts left switched on can be worked through against a real codebase with the prompt pack.
Where this came from
A list assembled from things found after the fact rather than from a security framework. It is deliberately short and deliberately ordinary — the exotic failure modes are well covered elsewhere and are not what catches people shipping alone.
Claude Code Operator covers the launch checklist in its wider form.
Tools in this piece
| Tool | What it does | Price |
|---|---|---|
| Supabase | Database, accounts and file storage in one, with no backend work. | Free tier |
| Vercel | Hosting. Puts a project live on a real address with one command. | Free tier |
| Stripe | Payments and subscriptions. The standard, and integrating it is a matter of asking. | Free, percentage per sale |
| Resend | Transactional email that actually arrives. | Free tier |
Every tool has its own page with the price, who should skip it and what to check before paying. Some links are affiliate links.
Questions people ask
What gets left switched on at launch?
Test accounts with weak passwords, seeded demo data, a debug or health endpoint that returns configuration, permissive access rules added while developing, a payment provider still in test mode, verbose error messages, and an email sender still pointing at your own address.
Why do these survive to launch?
Because each was added deliberately to unblock something, and the thing it unblocked then worked. Nothing fails afterwards to remind you, which is exactly why a list beats memory.
Is a test account with a weak password really a problem?
Yes, and more than a weak user password, because test accounts are usually given elevated permissions to make development easier. It is the most privileged account on the system with the least memorable password.
How do you catch a payment provider left in test mode?
Make one real purchase with a real card and refund yourself. It is the only check that exercises the whole path, and it also verifies delivery, the receipt email and the thank-you page at the same time.
Should error messages show details in production?
Not to the visitor. A stack trace tells someone your framework, file layout and sometimes your query structure. Log the detail where you can read it and show the visitor a sentence.
When should you run this check?
The day before launch, not the morning of. Several items take longer to fix than to find, and finding them an hour before you announce something is how launches slip.