12 things between your prototype and real users.

Your app works. That is the hard part, and you already did it. What follows is the other list — the one nobody hands you when the demo starts working, and the one that decides what happens the week strangers arrive.

Tick the ones that are true of your app right now. Nothing is sent anywhere — the count below is worked out in your browser and stored nowhere, including by me.

The checklist

1. Someone can be logged in as somebody else. The check that says who you are happens in the browser, or the user id arrives in the request and is believed. If the answer to “how do you know this is really them?” is anything the customer can edit, tick it.
2. A key that costs money is readable by anyone. Anything sent to the browser is public — bundlers do not hide it and minifying is not encryption. If your model, email or payment key is in the front end, it belongs to whoever opens the page.
3. Nothing caps what one visitor can spend for you. A single script hitting your model endpoint overnight is the cheapest way to wake up to a four-figure bill. Tick it unless there is a limit per user and a ceiling on the account itself.
4. You have never restored the backup. Not whether a backup exists — that one almost always passes. Have you taken the file and rebuilt a working database from it? A backup nobody has restored is a belief, not a backup.
5. The customer’s browser decides the price. If the amount, the quantity, the discount or the plan arrives from the page and is charged as received, then the page belongs to the buyer and so does the price.
6. You could not reconstruct yesterday. Who signed in, what failed, what got deleted. With no logs you cannot answer a customer’s question, and you cannot tell whether something has already happened to you.
7. A secret is in the repository history. Deleting the line does not remove it — it stays in every earlier commit and in every clone and fork. If a key was ever committed, it is still there until it is rotated.
8. You do not know which law applies to what you collect. Email addresses and names are personal information. Canadian federal law, Quebec’s Law 25 and the European GDPR each ask different things, and which ones apply depends on where your users are — not where you are.
9. Your customers would find out before you did. If the site goes down at 2am, what tells you? Tick it unless something actually watches and actually reaches you.
10. The domain or the email could be taken from you. Registrar and DNS accounts without two-factor, a domain on a personal address you no longer read, a renewal on an expired card. Losing the domain loses the business, and it is the cheapest thing here to fix.
11. Shipping a fix is done by hand and by memory. Files copied to a server, a step done in the right order because you remembered it. That works until the day you are in a hurry, which is the same day you most need it to work.
12. There is no plan for the bad day. What gets turned off first, how you go back to the last version that worked, what you tell customers, and who you call. Deciding that calmly in advance takes an hour. Deciding it during takes the whole day.

What the number means

Not much on its own, and it is not a grade. Every one of these is normal in an app that was built to see whether the idea worked. They are only a problem on the day the app stops being a prototype, and that day is usually decided by someone else — a first customer, a link that travels further than you expected.

None of the twelve needs me. They are written plainly on purpose, and a patient founder with a weekend can close most of them. Numbers 7 and 10 are worth doing this week whatever else you decide: rotating a leaked key and turning on two-factor at the registrar are an afternoon between them, and both get harder the longer they wait.

If you would rather not