Finished something? Before you share the link…
Is it safe to share?
Three fears. Three checks you can run yourself.
The most common reason a finished beginner app never gets shared isn’t quality — it’s worry. Is a secret key showing? Can a stranger see someone else’s bookings? Could this thing run up a bill on me? Those are three specific fears, and each one has a specific check — in plain words, most of it done by you, by hand, because your own test is the proof. Run all three before the link goes out.
Honest scope: this is a beginner self-check, not a security audit. It catches the three common leaks. A pass here means “these three doors are shut” — it does not mean “this app is secure”, and anyone who sells you that sentence for a checklist is selling something.
Fear 1 · A secret key is visible in my page
Some keys are house keys — whoever has one can walk in, read everything, or run up charges. Those belong on a server only, never inside a web page. Other keys are a mailbox address: meant to be public (services hand out “publishable” / “anon” keys designed to ship in the page), and safe only because the data behind them is locked down — that's Fear 2. Trouble starts when a house key ends up in the page.
The check
Safe looks like
No secret (server-only) key anywhere in what a visitor's browser downloads — and every key that IS in the page is public-by-design, in a list you now hold.
If it fails
Don't share the link yet. Move the key server-side (the prompt's fix), and treat the old key as burned: rotate it at the service that issued it, because anything that was public must be assumed copied.
Fear 2 · One user can see another user's stuff
Your app has logins and saved things — bookings, notes, photos. If the data rules are loose, any logged-in user can peek at everyone else's — sometimes just by changing a number in the address bar. It's the most common real leak in beginner apps, and the easiest to test yourself. This test is done by hand on purpose: you are the proof.
No logins and no saved user data in your app? Then this fear honestly doesn't apply — a static page has nothing of anyone's to leak. Tick it done and move on.
The check
Safe looks like
B can't see A's thing anywhere — not in lists, not by the direct address, not logged out. B sees only B's things.
If it fails
Don't share the link yet. Run the fix prompt — then re-run this test yourself afterwards. An AI saying “it's fixed” is not the test; the test is the test.
Fear 3 · It runs up a bill on me
Your app calls a paid service — an AI, maps, email sending, image processing. If a call can be triggered by visitors, retried in a loop, or left uncapped, a busy day (or one mischievous visitor) becomes your invoice.
The check
Safe looks like
Every paid call has a ceiling you chose — a provider-side cap, a limit in the app, or both — and you know the worst-day number before it happens.
If it fails
Set the provider cap first (yours to do, takes minutes), then apply the prompt's bounded fix before sharing widely. A friends-only link while a fix is pending is a reasonable middle state; a public launch isn't.
The verdict
Work through the three cards above. A fear only counts as passed when you ran its check — not when an AI says it’s probably fine. Anything that fails gets its fix above, then the same check again.
Something broke along the way and the error might as well be in another language? That’s error first aid — plain English, plus the one bounded fix prompt. Want an independent verdict on the whole app before sharing? /review grades it against your requirements with a different model.
The ticks on this page live only in this tab — nothing here is sent anywhere or stored by this site. The checklist file is yours to keep with the project.