Skip to main content

Launch Readiness Checklist

Is your app ready for the rest of the company?

Thanks for signing up. Here's how to use this:

  1. Open the AI tool you built the app with (Lovable, Bolt, Replit, Cursor, Claude, or whatever you used). If it has a chat-only, "ask", or planning mode that won't make changes, use that.
  2. Paste in the setup prompt below first. It tells the AI to look and explain, not change anything.
  3. Work through each check. Copy the prompt, read the answer, and mark the result green, yellow, or red. If you're not sure, say so. That's useful information too.
  4. At the end, you'll get an overall result and a summary you can send to your manager or IT team.

Your answers are saved in this browser only, so you can come back to it. Nothing is sent anywhere unless you choose to send it.

A word of warning about AI answers

AI tools tend to be confident and want to reassure you. If an answer sounds too tidy, follow up with "Show me exactly where in the code that happens" or "What would a security reviewer worry about here?" And if it can't show you, treat it as yellow.

Step 1: The setup prompt

I'm not a professional developer. I built this app with your help and my company is thinking about rolling it out to more people. I'm going to ask you a series of questions to check whether it's ready.

For every question:
- Do NOT change any code or settings. Only look and explain.
- Answer in plain language that a non-developer can follow.
- Point to the specific files or settings you're basing your answer on.
- If you're not sure, or you can't see something, say so. "I don't know" is a useful answer. Don't guess.
- If something is a real risk, say so clearly. Don't soften it to be nice.

1. Who can get in

The most common gap in AI-built apps. A login screen can look finished without actually keeping anyone out.

1. Does everyone have to sign in, and is the sign-in solid? Essential

If any page or piece of data can be reached without signing in, anyone who finds the address can see it. Home-made login systems are also easy to get subtly wrong.

Ask your AI tool

How does signing in work in this app? Please tell me:
1. Is there any page, screen, or piece of data that can be reached without being signed in? Check the server side, not just whether the button is hidden.
2. Does it use an established login service (for example Google or Microsoft sign-in, Supabase Auth, Clerk, Auth0, Firebase Auth), or did we build our own?
3. If we built our own, how are passwords stored?
Your result

2. Can people only see what they're supposed to? Essential

Signing in proves who someone is. It doesn't stop them from seeing someone else's records. A classic gap is being able to change a number in the web address and see another person's data.

Ask your AI tool

Once someone is signed in, what decides which records they can see and change?
1. If a user changed an ID in the web address or in a request (for example /orders/12 to /orders/13), would the app stop them from seeing something that isn't theirs? Show me where that check happens on the server.
2. Are there different kinds of users (for example admins vs. regular staff)? Where is that enforced?
3. If the app uses a hosted database like Supabase or Firebase, are its access rules (sometimes called "row level security" or "security rules") turned on and actually restricting anything?
Your result

3. Are passwords and keys kept out of sight? Essential

Apps connect to other services with secret keys. If those keys end up in code that runs in the browser, or in a shared code repository, anyone can copy them and use your accounts, sometimes at your expense.

Ask your AI tool

List every secret key, password, or token this app uses to connect to other services (for example database, email, payments, AI services).
For each one, tell me:
1. Where is it stored? Is it written directly in the code, or kept in a separate settings/environment file?
2. Could it end up in the code that's sent to people's browsers?
3. Has it ever been committed to the code history (for example on GitHub), even if it was removed later?
Your result

4. When someone leaves the company, can you lock them out?

Companies already have a process for removing access when people leave. An app with its own separate accounts falls outside that process, so ex-employees can keep access without anyone noticing.

Ask your AI tool

How are user accounts managed in this app? If an employee leaves the company, what are the exact steps to remove their access? Is there any way to sign in with our company accounts (for example Google Workspace or Microsoft 365) instead of a separate username and password?
Your result

2. Whose data is it

Your company almost certainly has rules, and possibly legal obligations, about what information goes where.

5. Do you know exactly what information the app stores? Essential

Customer names, email addresses, financial details, and health or HR information all come with obligations. Privacy laws (like PIPEDA in Canada, or GDPR in Europe) apply whether the app was built by a developer or by AI.

Ask your AI tool

Make me a plain-language list of every type of information this app stores or handles. Group it into: information about our customers, information about our employees, financial information, and anything else. Flag anything that would count as personal or sensitive information (names, contact details, ID numbers, financial, health, HR).
Your result

6. Do you know where the data is stored, and who stores it?

Your data lives on someone else's servers: a database service, a hosting company, a file storage service. Many companies have rules about which vendors are approved and which countries data can be stored in.

Ask your AI tool

List every outside service or company that stores or receives data from this app (for example the database host, file storage, email service, analytics, error tracking). For each one, which account is it under, and if you can tell, which country or region is the data stored in?
Your result

7. Does the app send company data to an AI service?

If the app uses AI features (summarizing, drafting, chat), the information goes to that AI company. Your company may have a policy on which AI services are allowed and what can be sent to them.

Ask your AI tool

Does this app send any information to an AI service (for example OpenAI, Anthropic, Google)? If so, which features do it, exactly what information gets sent each time, and which account and plan is being used?
Your result

3. When things go wrong

A demo never has to answer these questions. An app people depend on answers them every week.

8. If the data disappeared tomorrow, could you get it back? Essential

Data gets lost through bad updates, accidental deletes, and service outages. The question isn't whether backups are turned on. It's whether anyone has ever actually restored one.

Ask your AI tool

Is the data in this app backed up? Tell me:
1. What's backed up (the database, uploaded files, both)?
2. How often, and how far back can we go?
3. What are the exact steps to restore a backup, and has that ever been done?
4. If someone accidentally deleted a bunch of records, how would we get just those back?
Your result

9. Would anyone know if something broke?

When something fails in a prototype, you see it on your screen. When it fails for a colleague at 4pm on a Friday, you may never hear about it, or they may just stop trusting the app.

Ask your AI tool

What happens when something goes wrong in this app, for example a save fails, an outside service is down, or there's a bug? Does the user see a clear message? Is the error recorded anywhere? Would I or anyone else get notified? Are there places where a failure would happen silently?
Your result

10. Does it hold up to real, messy use?

Your own test data is tidy. Real people type things wrong, double-click buttons, upload huge files, and edit the same record at the same time.

Ask your AI tool

Look for places where real-world use could cause problems:
1. What happens if two people edit the same record at the same time?
2. What happens if someone double-clicks a save or submit button?
3. Is what people type checked on the server (for example required fields, valid emails, sensible numbers), or only in the browser?
4. Are there any limits on file uploads (size and type)?
List anything that could lead to lost, duplicated, or corrupted data.
Your result

4. Where it runs and what it costs

Prototypes often run on free plans and personal accounts. That's fine for a prototype and risky for a tool the company depends on.

11. Is it running somewhere the company controls?

If the app runs on your personal account or credit card, it's tied to you. If your card expires, you go on leave, or you move on, the app can go down with no one able to get it back.

Ask yourself

Whose account and credit card is each of those under?

Ask your AI tool

Where is this app running right now? List every service and account it depends on to stay online (hosting, database, domain name, email, and so on). For each one: is it a free or paid plan, and are there limits on that plan that we could hit (for example usage limits, the app going to sleep when idle, or data limits)?
Your result

12. Do you know what it will cost with real usage?

Services that are free or cheap with one user can behave very differently with fifty. AI features especially can get expensive fast, because you pay every time they're used.

Ask your AI tool

Which parts of this app cost money based on how much it's used (for example hosting, database size, file storage, emails sent, AI requests)? Roughly what would it cost per month with 50 people using it every day? Are there any places where one person could accidentally run up a big bill, for example by triggering lots of AI requests?
Your result

5. Keeping it alive

AI-generated code tends to be written for right now. Someone has to be able to look after it six months from now.

13. Is the code somewhere the company owns?

If the code only exists inside your AI tool account or on your laptop, the company doesn't really own the app. A copy in a company-owned code repository (like GitHub) means someone else can pick it up.

Ask your AI tool

Where does the code for this app live? Is it saved in a code repository like GitHub, and does it have a history of changes? Write a short summary of how the code is organized, so that a developer seeing it for the first time could understand it. Is there a README file explaining how to run it?
Your result

14. Are its building blocks up to date?

Every app is built on dozens of open-source packages. When security problems are found in them, they need updating, and AI tools sometimes pick old versions to begin with.

Ask your AI tool

What outside packages and libraries does this app depend on? Are any of them out of date, no longer maintained, or known to have security problems? If you're able to run a security check on the dependencies (for example "npm audit"), please do and explain the results in plain language. Don't fix anything yet.
Your result

15. Can you make changes without breaking things for everyone?

Once people depend on the app, every change is a risk. Professional apps have a test copy to try changes on first, and automated tests that catch things that break.

Ask your AI tool

When I ask you to change this app, where do those changes go? Do they go straight to the live version that people are using, or is there a separate test copy? Are there any automated tests? If a change broke something, how would we undo it?
Your result

6. Getting your company on board

This is where internal tools most often get stuck, and none of it is about code.

16. Does IT know the app exists?

IT teams aren't there to shut things down, but they are responsible for company data and security. Finding out about an app after it's in use is what tends to get it shut down.

Ask yourself

Has anyone in IT, security, or whoever looks after technology at your company seen this app? Do you know if there's an approval process for new software?

Ask your AI tool

Write a one-page summary of this app for our IT team, in plain language. Include: what it does, who uses it, what information it stores, which outside services and accounts it relies on, how people sign in, and any risks or gaps you're aware of. Be honest about the gaps. This is to start a conversation, not to get it approved.
Your result

17. If you were away for a month, who would look after it?

Right now, you're probably the only person who understands the app. That's fine until you're on vacation, on leave, busy with your actual job, or move on.

Ask yourself

If the app broke while you were away, who would people call? Could that person get into every account the app depends on?

Your result

18. Is building tools this way allowed where you work?

Many companies now have policies on AI tools: which ones are allowed, and what company information can be put into them. It's worth knowing before the app is in wider use.

Ask yourself

Does your company have a policy on using AI tools, or on approved software and vendors? Did building the app involve putting company information into the AI tool?

Your result

Your result

0 of 18 checks answered.

Work through the checks above to see your result.

  • 0 green
  • 0 yellow
  • 0 red
  • 0 not sure

A summary for your manager or IT

This updates as you go. Fill in the details, then copy it into an email and edit it however you like.

Want a second opinion?

The Launch Readiness Review

A checklist can only go so far. You're still relying on the AI to grade its own work. If you've got some yellows and reds, or the app matters too much to guess, I'll look at it properly.

I go through your app's code and setup myself, and give you a written report in plain language:

  • What's solid, and what's a real risk, ranked by how much it matters
  • Whether to strengthen what you have or rebuild it using your app as the blueprint
  • A rough cost and timeline for each option
  • Written so you can forward it to your manager, IT, or whoever holds the budget

$1,500 CAD, fixed price. If you hire me to do the work afterwards, the full $1,500 comes off the cost of the work.

This doesn't commit you to anything. I'll reply to confirm the details and how to share access to the app. Not ready for that? Book a free call instead.