A web app launch checklist is the list of things a tool needs before strangers, and their money, touch it. For a tool I built for myself, that list is one line: does it work for me? For a paid product it covers security, legal pages, payments and help for people who can’t just ask me. Mine is a starter list, not a complete one, because I don’t know what I don’t know. A generator below starts yours.
Green twice, with 25 problems still live
In August I asked Claude a simple question about App Hub, the bundle where one Pro plan opens five of my apps: is it 100% ready?
A quick check of the front door had already come back all green. Twice. Then a full pass, logged in, clicking everything and forcing things to fail on purpose, turned up 25 problems that were live right then. A few of them:
- A server error showed a bare error page and skipped the alert email that’s supposed to tell me something broke.
- Typing the wrong current password logged you out.
- Someone whose Pro plan had lapsed saw “Pro active until” a date in the past, with no button to renew.
- The checkout success link told free accounts they were Pro.
- When the verification email failed to send, the screen still said “we emailed a code.”
- The signup notification had never once reached my n8n.
Every one of those lived behind a login or a failure, the places a quick look never goes. And I’d been told for a while that things were fixed, only to keep finding them again. So that day I asked for a real test, one that runs every time, and I told Claude: “build the gate. but keep everything else, too. i want everything as safe and ready to go as possible.”
That’s the readiness gate, and it’s most of what’s on my checklist now.
Should you turn a tool you built for yourself into a product?
Only if other people want it and you’re ready for the work that comes after building. I’ve popped up lots of little tools for my personal life and my business. A few of them seemed like they’d help other people too. But turning one into a product adds so many more layers, especially once you plan to charge money.
Plenty of my tools stay just for me, for three reasons:
- They’re built for one or two people. My meal planner is just for my house. A couple of others are just for me and my husband, or me and my sister. They fit our lives, not a stranger’s.
- They’re not worth the layers. A small tool doesn’t justify logins, legal pages and payments.
- There’s no real demand. I didn’t care about that until I got into it. I made Giveaway Widget even though giveaway tools aren’t in high demand anymore, but I did it anyway. Now I know how many extra steps it takes to fully launch a product, and a lot more of my tools stay just for me.
When you should turn it into a product:
- People outside your house have asked for it, or would pay for it.
- You’re willing to keep testing it after every change, for as long as it’s for sale.
- You’d be comfortable with a stranger’s money and data inside it.
When you shouldn’t:
- It only works because you know its quirks.
- You’d be building the product part mostly to see if anyone shows up.
- You don’t want to answer a stranger’s support email about it.
What does a web app launch checklist need to cover?
It needs to cover four layers a personal tool never has: security, legal pages, payments, and help for strangers. Each one lines up with something that scares me once other people’s money is involved.
| Layer | When it’s just for me | When strangers pay for it | What I worry about |
|---|---|---|---|
| Security | A password, if that | Hashed passwords, lockouts, rate limits, security headers | Someone’s data leaks |
| Legal pages | Nothing | Privacy, terms, Do Not Sell and accessibility pages, my LLC name and address in the footer | Legal trouble |
| Payments | Nothing | Checkout, what turns on after paying, failed and lapsed payments, renewal warnings | Someone pays and nothing turns on |
| Help | I already know how it works | A guide page, a help panel, a tour, tips and hints | Looking careless in front of a paying customer |
Security
I take things loads more seriously when I’m dealing with people’s money. On my paid apps, passwords are hashed and salted, so they’re never stored as typed. An account locks after a few wrong tries. Logins expire, and changing your password signs out every old session. Every response carries security headers, and each app’s API only answers the web addresses on its list. I don’t check those by hand. They’re all on the test list, so Claude checks every one of them, every time.
Legal pages
My checklist says a paid app gets privacy, terms and Do Not Sell pages linked in the footer, plus an accessibility page, my LLC name and postal address, a way to export your data, and an email 30 days before an annual plan renews. Writing this post, I found two of my own apps still missing a piece of that list, which tells you how easy it is to skip one. I’m not a lawyer, and none of this is legal advice. It’s the list I keep so I don’t forget a page.
Payments
Payments break without making a sound. Stripe tells the app a checkout finished, and the app turns Pro on. At one point Stripe changed the shape of the data it sends, and my renewal sync and affiliate tracking skipped right over it. Nothing crashed. Nothing emailed me. That got fixed in three apps once I found it, and it’s why failed and lapsed payments are on the test list now, not only the happy path.
Help for strangers
When I’m the only user, I know where everything is. A stranger doesn’t, and they can’t text me to ask. My apps get five layers of help: a public guide page with screenshots, a “?” panel you can reopen anytime, a guided tour, a rotating tips card and small hints right next to the buttons. A popup on your first visit doesn’t count as any of them, because you close it and it’s gone.
How do I test a web app before launch?
I test it after every change, not only before launch. I’m very paranoid about it and make Claude do extensive testing every time something changes, because a fix in one spot can break another. The readiness gate runs in six steps:
- The existing checks. A quick front-door sweep, a security test and a pre-deploy audit.
- Every page. An accessibility scan, no sideways scrolling on a phone-sized 390-pixel screen, my banned words, security headers on every web address, and the Back button pressed three times.
- Every button. It clicks every control, logged out and then logged in.
- Real flows on the live site. It logs in, reads the password reset link out of the real delivered email, goes to checkout up to the payment page, cancels and comes back, exports data, and tries wrong passwords.
- Failure on purpose. Offline in the middle of something, an expired session, a failed payment, a lapsed Pro plan, an email that won’t send.
- Two auditors. Two separate AI agents read the results. One looks at security. The other checks that each button did what its label says.
Anything it can’t check comes back yellow with a reason, never a silent skip, and yellow isn’t green. App Hub went from 223 green checks on its first run to 347 now, because new problems keep turning into new checks.
Step 4 is there because of an email. My login and password reset links were broken in six apps, and the code looked perfect. Email mangled the “=” in the link on its way to the inbox, so only the email you actually received was broken. A test that reads the code would never catch it. A test that reads the real email does.
Two more habits run alongside the gate. Before every deploy, Claude runs an audit for leaked keys, open routes and exposed files, which started after one of my own dashboards turned out to be public when it shouldn’t have been. And after every deploy, it checks the live app, because a deploy can wipe settings while the health check still says everything’s fine.
In October I had Claude run a deeper security audit on 12 of my live apps. It found 4 serious problems and 6 medium ones, in apps that had all passed that pre-deploy audit. So the audit got six new checks:
- Anything that costs me money each time it runs, like an AI call, an email or a checkout, has a daily limit that survives a restart.
- An app never decides who you are, or whether you’re Pro, from what your browser tells it.
- You can only reach your own data.
- No secret keys in any file your browser downloads.
- No admin key names in that code either.
- Database queries never get pieced together from text, which is how attackers slip their own commands in.
The audit also stopped being something Claude has to remember to run. A deploy now gets refused until it passes. Tested on the code from before the fixes, it blocked all 4 serious problems.
Is this a complete web app launch checklist?
No. It’s a starter list, the one I’ve built so far from my own apps, and almost every item got there because something broke or I went looking. I don’t know what I don’t know, and a checklist can’t know it either. That’s why mine keeps growing. App Hub went from 223 checks to 347 in about a month.
Three things this list can’t do for you:
- Know your app. Yours will have logins, data or payment setups mine don’t, and those come with their own checks.
- Stand in for a professional. I’m not a lawyer or a security expert. If your app handles health info, money or anything regulated, get real advice for that part.
- Stay finished. Rules change, tools change and new problems show up. A list that was right last year can be missing things today.
So use it as a place to start, add to it every time you find something, and when you’re not sure, ask someone who knows more than you do. More than me, too.
Get the generator
The generator asks about your tool: who uses it, whether people log in, whether it takes money, what data it keeps and whether it sends email. Then it builds a launch checklist sized to what you told it. A tool for you and your family gets a short list. A paid app with logins gets the long one.
It also writes a testing prompt you can paste into Claude Code after every change, and a Claude Code skill if you’d rather have it on hand. Treat all of it as a starting point. It’s the list of questions I ask about my own apps, and your app will have things mine don’t.
What it doesn’t do
The generator doesn’t know your app. It can’t test anything, and it won’t catch a problem your app has that mine never did. A checked box means you looked, not that you’re safe. It isn’t legal advice either. It’ll remind you a privacy page exists, not what yours needs to say.
My own gate has limits too. It never completes a real purchase, so the full path from paying to Pro turning on still needs a person. The account it tests with is free, so Pro-only screens don’t get clicked on the live site. And I still find things. Now each one gets added as a check.
The new security checks read how the code is written, so they catch the kinds of mistakes I’ve already found. A brand new kind can still get past them. Once a month, AI agents run the full security audit again from scratch to look for what the checks miss.
Frequently asked questions
What should be on a web app launch checklist?
Security, legal pages, payments and help for new users, plus a way to test all four after every change. My list covers hashed passwords and lockouts, privacy and terms pages, what happens when a payment fails, and a guide page with screenshots. A tool only you use needs far less. Any list, mine included, is a place to start, so add to it as you learn what your app needs.
Is an app built with Claude Code safe to sell?
It can be, if you test it like it’s going to fail. Claude Code writes the app fast, and in my experience the checking only happens when I ask for it. I have it run a security audit, click every button and force failures after every change, and it still finds things.
Should I charge for a tool I built for myself?
Only if other people want it and you’ll keep testing it for as long as it’s for sale. Charging money adds security, legal pages, payments and support to a tool that didn’t need any of them. Plenty of mine stay just for me, and that’s fine.
How do I test a web app after every change?
Have one test that runs the same way every time. Mine checks every page, clicks every button logged out and logged in, runs real flows on the live site, forces failures on purpose, then two AI agents review the results. Anything it can’t check is marked yellow instead of skipped.
Does a launch checklist guarantee my app is safe?
No. A checklist tells you what to look at, not whether you found everything. Mine keeps growing because new problems keep turning up, and every one becomes a new check.
Try it yourself
A web app launch checklist for a paid tool covers security, legal pages, payments and help for strangers, and it only works if you test against it after every change, not once before launch. Decide first whether the tool should be a product at all. Plenty of good tools should stay yours.
If you’re going ahead, start with the generator above and add to it every time you find something. And point your automations at an n8n error workflow so a failure emails you instead of waiting for a customer to mention it. If you’re on Claude Code, the security plugin I run is in my list of Claude Code plugins for non-coders.
A book I made
Sell It or Shed It
A declutter workbook for making money from what you don’t use. One closet or drawer at a time: dump what’s in it, mark each thing sell or shed, list five, and set a thirty-day check date.
Clear your first zone →I run an affiliate program on the tools I build. Approved affiliates earn 20% on what their referrals pay, for up to a year. US only for now. See the program →
Related reading
- How I Stopped Rebuilding Things I’d Already Built
- Why My Gamified Cleaning App Didn’t Stick
- Software Subscriptions I Canceled Because I Built My Own
- n8n Error Workflow: How I Stop Finding Out Days Later
Subscribe if you haven’t already. I’m always building something new, and I’ll keep writing up the parts that broke. In the meantime, go forth and automate the boring stuff.
