A pre-launch checklist for an app you didn't fully build yourself

A lot of the people I talk to didn't write a line of their own app. They paid a freelancer, hired a small shop, or sat down with Cursor or Lovable and described what they wanted until it worked. That's a completely normal way to end up with software in 2026, and none of it is a problem by itself. The problem shows up later, at the moment someone asks "so is this actually ready to put customers on," and the honest answer is: nobody knows, because nobody who built it stuck around to check. This is the pre launch web app checklist I'd hand that person — copy it, run it yourself, no technical background required.

I've written before about the individual gaps that show up in AI-built apps — the missing row-level security that lets one user see another's data, the missing rate limits that turn a good day into a 3am bill, the handful of security holes AI tools leave by default. This post pulls all of it into one list, grouped by layer, phrased as questions you can answer yourself without opening a terminal.

Why "someone else built it" changes nothing about the risk

Here's the thing that surprises people: whether you wrote the code, an agency wrote it, or an AI tool wrote it in an afternoon, the app faces the exact same internet. The same bots scan for open signup forms. The same customers expect their data to stay private. The same traffic spike either gets handled or doesn't. Ownership of the build has nothing to do with exposure once it's live — the only question that matters is whether the thirteen layers below actually got covered, and "I paid someone" isn't an answer to that question, it's just a different way of not knowing.

The checklist — 13 layers, yes or no

Go through each one honestly. A "no" or an "I don't know" both count as a gap.

Frontend & user experience
1. Does every form show a real error message when something goes wrong, instead of a blank screen or a spinner that never stops?
2. Does the app work on a phone, on a slow connection, not just on the laptop it was demoed on?

Auth & access
3. Is there a server-side check on every protected action — not just a button that's hidden in the UI, but an actual rejection if someone calls the API directly?
4. Can a logged-out user, or a user in the wrong account, actually reach pages or data they shouldn't?

Data isolation
5. If you're logged in as User A, can you edit a URL or an ID and pull up User B's data? (This is the row-level security question, and it's the one I'd check first.)
6. Do database-level rules enforce that isolation, or does it only exist because the app's UI happens not to show you the button?

APIs & secrets
7. Do any API keys, database credentials, or admin secrets appear anywhere in the code your browser downloads?
8. Do API responses return only what the screen needs, or do they hand back entire database rows — including fields you never intended to expose?

Traffic & cost
9. Is there a rate limit on signup, login, and any endpoint that costs money per call (AI features especially)?
10. Is there caching anywhere, or does every single page load hit the database and any paid API fresh, every time?

Hosting & resilience
11. Does the app run on more than one instance, or does a single server falling over take the whole thing down?
12. Are backups actually running, and — this is the part everyone skips — have you ever tested restoring one?

Input & validation
13. Is user input validated on the server, not just in the form on the page, before it touches your database?

The two that are non-negotiable

Every layer above matters, but two of them are hard blockers, not nice-to-haves. If the answer to #3 (server-side authorization) or #5 (data isolation) is "no" or "I'm not sure," the app doesn't go live with real customer data on it — full stop. Everything else on the list is a matter of how much risk you're comfortable carrying at launch. Those two are the difference between "a rough edge" and "a stranger reading your customers' information," and that gap doesn't announce itself in a demo. It just sits there until someone finds it.

FAQ: do I need to redo the whole build?

No — and this is the part that tends to come as a relief. Almost none of the 13 layers require throwing out what you have and starting over. Row-level security gets added to an existing database; it doesn't need a rewrite. Rate limits and caching sit in front of the app you already have. Server-side auth checks get bolted onto the endpoints that are missing them. The freelancer or the AI tool did the hard, visible work of making the app exist and work the way you described. What's usually missing is a second, narrower pass focused only on the boring layers — the ones nobody thinks to ask for because they don't show up when you click around a demo. That's a few days of focused work, not a rebuild, and it's a lot cheaper before launch than after.

Your Turn: pull up the app right now and go through all 13 questions with whoever can actually answer them — the freelancer, the agency, or your own memory of what you typed into the AI tool. Count the honest "no"s. If it's more than a couple, or if either non-negotiable fails, that's not a reason to panic — it's a reason to get a second set of eyes on it before launch day does the finding for you.

See how the Launch-Ready Audit works →

— Kyle Tysvaer, Founder, Insightful Eye Marketing