The launch checklist for an AI-built app

Getting an app to run and getting an app ready for real users are two different jobs. The first is the hard, creative one, and if you’ve built something with AI that works and that you can send someone a link to, you have done it. The second is quieter, and almost none of it shows on screen. The app looks the same the day before a data leak as the day after.

This is the full list I work through before an AI-built app meets real people, with the concrete points under each area rather than the tidy top-level version. Seeing the whole thing in one place is the fastest way to understand why launching well is a job of its own. You don’t need to do every item today, and you don’t need to do it alone, but you should know what’s on the list.

I have grouped it into eight areas. Roughly the first half is about not getting hurt, and the second half is about holding up once people arrive. Where I’ve written about something in more depth elsewhere, I have linked to it.

1. Security

Security is the part with the sharpest edges, because a mistake here can cost you money or data overnight, and it’s invisible from the outside until someone finds it.

Authentication and sessions. How people log in, and what happens to a session afterwards. Passwords stored hashed rather than in plain text, sessions that expire, reset links that can’t be guessed or reused to take over an account. If you use an off-the-shelf provider like Supabase Auth or Clerk, the hard parts are handled and the mistakes live at the edges.
Access control. Whether people can only see and do what they’re meant to. AI builds the main path well and tends to miss the guard that stops one user reaching another’s data. This is the most common serious flaw I find, and I’ve written a whole piece on how to test it: can your users see each other’s data?
Secrets and API keys. Keys for the database, the AI API, the payment provider. A key that reaches the browser has effectively been published, and AI builders often put keys wherever is convenient. Check what your app is handing out, and move any real secret onto the server. The security piece, how to keep your vibe-coded app secure, walks through finding them.
Input handling and injection. Whether user input can reach your database or another user’s screen in a way it shouldn’t, the flaws known as SQL injection and cross-site scripting. Generated code is usually fine here when it uses a modern library, and dangerous when it builds queries or HTML by gluing strings together.
Dependency vulnerabilities. Third-party packages with known holes. Generated projects often pin versions that were already a year out of date. npm audit in the project folder lists them, and most close with an update.
Rate limiting and abuse. Whether a form, a login or an expensive endpoint can be hammered. Try submitting something fifty times in a row. If nothing stops you, nothing stops a bot either, and that’s how you get a spam problem or a bill.

2. Privacy and data protection

If you hold personal data, the law has expectations, and a template privacy policy doesn’t meet them on its own. I’m an engineer rather than a lawyer, so treat this as a practical starting point.

Lawful basis and consent. A clear reason for the data you collect, and a cookie banner that actually blocks non-essential cookies until someone agrees, rather than setting them on load and showing a banner for decoration.
How much data you hold. You only have to protect what you keep. Founders often collect fields they never use. Holding less lowers both your risk and your obligations.
Storage and encryption. Personal data encrypted in transit, which means https everywhere, and sensitive fields protected where they’re stored rather than sitting in plain text.
Where data goes. Every place your users’ data travels: analytics, email tools, and above all AI APIs. Sending personal data to an AI provider has real implications under GDPR, and a lot of founders don’t realise their app forwards user content to one at all.
Privacy policy and records. A policy that matches what the app actually does, including tools it really uses and leaving out ones it doesn’t.
Deletion and data requests. Being able to find, export and delete a person’s data when they ask. It’s a legal requirement that’s easy to miss until the first request lands. I go through all of this in what GDPR asks of your AI-built app.

3. Reliability and error handling

This is what decides whether a bad moment is a blip or a bad day. Generated code tends to assume everything works the first time.

Error handling. What the user sees when something fails. A handled error and a helpful message, rather than a crash or a raw stack trace with your internals in it.
Logging and visibility. Whether you can see what’s happening in production. When something goes wrong you want to read what happened, not guess.
Coping when things fail. What the app does when a third-party service or the database is briefly unavailable. A sturdy app carries on in a reduced way instead of falling over completely.
Backups and recovery. Whether your data is backed up, and whether a restore would actually work. A backup you have never restored is a guess. Plenty of products launch with no real backup until the first bad day, which is why I wrote would your app survive losing its database?
Data integrity. The race conditions and missing validation that quietly let bad or duplicate records into your database, the kind you only notice weeks later when the numbers don’t add up.

4. Performance

Speed is a feature, and it’s usually fine with five rows of test data and painful with five thousand real ones.

Load and responsiveness. How quickly your key pages load and become usable. A slow first impression loses people before they ever sign up.
Database queries. Slow queries, and the common pattern where showing a list of fifty things quietly runs fifty-one database queries instead of one or two. It’s the classic generated-code bottleneck.
Caching. Where expensive work and repeated requests could be cached, since the right caching cuts both your response times and your costs.
Asset sizes. Images served at full resolution, oversized scripts and bundles. These are often far larger than they need to be, and they’re among the easiest things to fix.

I pulled these apart, with the checks you can run yourself, in why your app gets slow with real users.

5. Scaling

Scaling is performance’s cousin: whether the app holds together as real users and real data arrive at the same time.

Handling many users at once. Whether the app can run on more than one instance and cope with simultaneous users without corrupting shared state.
Database capacity. Indexes, connection limits and room to grow, so the database isn’t the thing that falls over as usage climbs.
Long-running work. Slow jobs like sending email, generating an export or calling an AI API belong in the background, not blocking a request until it times out.
Third-party limits and cost. The rate limits and pricing of the services you depend on, especially hosting and AI APIs, so a busy day doesn’t break the app or produce a shocking bill.

6. Deployment and operations

How the app gets from your machine to the world, and how you find out when something is wrong.

Repeatable deploys. A release process that’s reliable and ideally automated, so shipping isn’t a nervous manual ritual every time.
Configuration and secrets. Configuration and secrets handled cleanly across environments, rather than hard-coded or shared between your development and live setups.
Rolling back. Being able to undo a bad release quickly. A rollback turns an outage into a minor blip.
Monitoring and alerts. Uptime checks and error alerts, so you hear about a problem from your tools rather than from an annoyed user.
Cost control. The things that cause bill surprises: uncapped AI usage, oversized infrastructure, missing budget alerts. I went through where the money leaks in how AI-built apps run up surprise bills.

If your app is still published straight from the builder, some of this is easier once you own the hosting. I’ve written the how and the why in why vibe-coded apps break in production and how to move your vibe-coded app onto hosting you own, and if you’re not sure it’s time yet, how to tell your app has outgrown its builder.

7. Code quality and maintainability

This is the area you can ignore longest and regret most, because it decides how easily you can change the thing, hire for it, or sell it.

Structure and readability. Whether the codebase is organised well enough for you or a future developer to change it safely. AI can produce a lot of code quickly, and it doesn’t always hang together, so a fix sometimes has to be made in three places.
Tests. Whether the important paths have any tests at all. Even a handful around signup, payment and your core action makes every future change less risky.
Dependency hygiene. Unused, duplicated or abandoned packages that quietly add weight and risk. AI often pulls in a library for one line and leaves it.
Documentation and handover. Enough written down that someone new can run the project and understand how it fits together. The real test is a clean clone on a different machine, which I dig into in could another developer take over your app?

8. Accessibility and correctness

Last, whether the app works for real people, on the devices and in the inboxes they actually have.

Accessibility basics. Keyboard use, colour contrast, labels and a sensible structure for screen readers, so you’re not shutting people out or falling short of your obligations.
WCAG compliance. How the product measures against the Web Content Accessibility Guidelines, the standard many organisations are expected, and increasingly required, to meet.
Forms and validation. Whether forms give clear feedback and handle mistakes sensibly, since that’s where most people get stuck.
Devices and browsers. How the app behaves across the browsers, screen sizes and devices your users have, rather than only the setup it was built on.
Email rendering. The emails your product sends. HTML email is inconsistent, and a message that looks right in one client can fall apart in another.

Most of this you can check yourself in an afternoon, and I’ve written the how in is your app usable for everyone?

How to use this list

Every launched product carries some of this unfinished. The trick isn’t to do all of it. The trick is to sort it.

Put every item into one of three piles. Before launch is the short list of things that could hurt a real person or your business on day one: exposed keys, access control, backups, the cookie banner, a hard cap on anything that costs money. Soon is what you want fixed in the first few weeks but not tonight. Later is real, but it can wait until you have users to justify it. Start at the top of the first pile and work down. Security and data come first because they’re the ones with consequences you can’t take back.

That sorting is most of the value, and it’s the part that’s hard to do on your own, because it’s difficult to rank a risk you can’t quite see. It’s also exactly what a Launch Plan is: I work through this whole list against your actual code and your running app, and hand it back in one prioritised order of work, in plain English, usually within one to two weeks. You keep the plan whichever way you go next.

You built the thing, which is the hard part. The rest of this is a specialist chore, and I’m happy to be the specialist.