A demo that works on your machine and a product that survives a launch to 100,000 people are not the same thing. Everything below is what we actually verify before we let a partner’s app take real, paying traffic — drawn from the checklists we run on our own launches. Check the boxes as you go; your progress saves in this browser.
We group this the way we triage a real launch: hard blockers that must be clear before a single real user arrives, do-before-wide items that are fine for a soft launch but must be fixed before you scale, and post-launch items that make you sleep better once you’re live. Order matters — work top to bottom.
Never mark something done that you haven’t actually verified. “It should work” is how launches break. If you can’t point at the thing that proves it, it’s not done.
If one of these is wrong, it doesn’t cause a bug — it causes a breach, a chargeback, or a headline. Clear these first, always.
No secrets in the client or the repo Blocker
API keys, database URLs, and tokens live server-side only. Grep your bundle and git history for sk_, secret, password, and provider key prefixes. Anything ever pasted into a chat, a screenshot, or a public commit is compromised — rotate it, don’t just delete it.
Every private route checks who, not just whether Blocker
Being logged in is not authorization. Confirm a user can only read and write their own data — try fetching another user’s record by changing the ID in the request. If it returns data, you have a hole. This is the single most common flaw we find in creator-built apps.
Webhooks verify their signature Blocker
Your payment webhook is a public URL that grants paid access. If it doesn’t verify the provider’s signature (Stripe’s whsec_, Apple’s notification signing), anyone can POST it a fake “payment succeeded” and unlock your app for free. Verify the signature before you trust the body.
Rate limits on anything expensive or public Do before wide
Login, signup, password reset, and any endpoint that calls an AI model or sends email needs a per-user or per-IP cap. Without it, one script can drain your AI budget or spam your users overnight. A KV counter per user is enough to start.
The moment you take real cards, mistakes stop being cosmetic. Test-mode keys shipped to production is the classic one — the app looks fine and takes zero real revenue.
You flipped from test mode to live mode Blocker
Recreate your products and prices in the provider’s live environment, swap sk_test for sk_live, and point the live webhook at your endpoint with the live signing secret. Then do one real purchase with a real card and refund it. Do not assume — verify the plan actually flips.
Entitlements survive a dropped webhook Blocker
Webhooks miss. If your only record that someone paid is a webhook that fired once, a single drop means a paying user loses access — or a churned one keeps it. Reconcile against the provider’s source of truth (a status check on read, or a nightly sync), and confirm paid access ends exactly when the subscription does.
The paywall is enforced on the server, not the screen Blocker
Hiding a button is not gating a feature. The server must reject a request for paid content from a free user, even if they call the API directly. If your entitlement check only lives in the UI, your premium features are free to anyone who opens the network tab.
A refund & cancel path exists and works Do before wide
Users must be able to cancel without emailing you, and you must be able to refund without a support nightmare. App stores and card networks require it, and it’s the fastest way to lose trust if it’s missing.
None of this is hard. All of it is required the moment you take money or collect data, and its absence is the first thing a diligent user (or an app reviewer) notices.
Privacy policy & terms are live and linked Blocker
Real pages, linked in the footer and the signup flow. They must name your actual legal entity and say what data you collect and why. Payment providers and app stores will reject you without them.
A real entity and support email are shown Do before wide
Card networks require a merchant identity. A named company, a support email a human reads, and a physical or mailing address. “Contact us on Instagram” is not a support channel for a paid product.
Users can delete their account & data Do before wide
Apple requires in-app account deletion for any app with account creation. Beyond compliance, it’s a trust signal: people share more when they know they can walk away cleanly.
AI output carries a disclaimer Do before wide
If your app gives advice from an AI model — health, financial, legal, anything consequential — say clearly that it’s AI-generated and not professional advice. This is real regulatory exposure, and it’s one sentence of copy to cover it.
These are the ones that pass every test on your laptop and then fail the day your audience actually arrives. The empty-state trap in particular has embarrassed more launches than any bug.
The empty state looks intentional, not broken Blocker
Your first real user sees an app with no content, no community posts, no data — because you tested it full. A brand-new user landing on empty screens thinks it’s broken and leaves. Seed real starter content, and design the “nothing here yet” state on purpose.
Error tracking is live before launch, not after Blocker
Wire up error tracking (Sentry or equivalent) and keep your logs open during the first hours. Without it you’re blind to real-user breakage — you’ll only hear about crashes from the users who bothered to complain, which is a fraction of the ones who just left.
You’ve sanity-checked the launch spike Do before wide
A creator launch isn’t steady traffic — it’s a wall of people the minute you post. Run a quick load test against your read paths, and confirm your database and rate limits hold. If you’re blasting it to a large audience at once, this is not optional.
One real, end-to-end run through the whole thing Blocker
In a fresh incognito window: sign up as a brand-new user, pay with a real card, land in the paid experience, use the core feature, then cancel. On a real device, not just the simulator. This one dry run catches more than any unit test — do it last, do it for real.
Shipping is the start of the work, not the end. These keep a live product healthy once real users depend on it.
You’re watching errors & the first purchases Post-launch
For the first day, actually watch: error rate, the first few real payments landing, and the webhook deliveries succeeding. Most launch problems are catchable in the first hour if someone is looking.
Regressions can’t ship silently Post-launch
Run your tests automatically on every change so a fix for one thing can’t quietly break another. Once real users depend on the app, “I’ll test it manually” stops scaling.
Your data is backed up and restorable Post-launch
Confirm your database has backups and that you’ve actually tested restoring one. A backup you’ve never restored is a hope, not a safety net.
This list is the floor, not the ceiling. It’s what a diligent solo builder can verify. The next layer — security review by someone who breaks things for a living, real load testing, app-store review strategy, and the operating discipline to keep all of it true as the app changes — is a full-time job. That layer is exactly what we do.
Drop your email and we’ll send you the full checklist as a clean PDF — the one we run — plus a short note on the two items builders most often get wrong.
No spam. The checklist, and we’ll only follow up if you want a real review.
Sent.
Check your inbox. If it’s not there in a few minutes, email [email protected].