Your AI-Built Application Works. Is It Ready for Production?

If you’ve used an AI coding assistant to build a customer portal, a booking system, an internal dashboard or a small SaaS product — and it works — congratulations. That is a genuine achievement, and a few years ago it would have required a development team.

“It works” and “it’s ready for production” are different statements, though. Production simply means real people, real data and real consequences: customers signing in, staff depending on it, money or personal information passing through it. The questions that matter at that point are less about whether the features work and more about what happens when someone uses them in ways you didn’t expect.

This checklist is written for business owners and founders who aren’t developers. You don’t need to answer every question yourself. But if you can’t answer one, that’s useful information: it tells you where to ask for help.

Why “it works” isn’t the whole story

AI coding tools are very good at producing code that does what you asked. They are less reliable at doing what you didn’t ask — and production readiness is mostly about things nobody mentions in a feature request.

A request like “let customers view their invoices” will usually produce a page that shows invoices. Whether it shows only that customer’s invoices, under every circumstance, is a separate requirement that may never have been stated. The same applies to error handling, backups, deployment, monitoring and cost. None of those show up in a demo.

The good news: most of the problems below are straightforward to fix once they’re identified. The expensive problems are the ones discovered by your customers first.

This is the most important section, because it’s where the most damaging problems usually live.

Who can sign in, and how? Is sign-in handled by an established authentication service or library, or was it written from scratch? Hand-built login systems are a common source of weaknesses.
Can one user see another user’s data? Try it. Sign in as one test user, note the address of a page showing that user’s record, then sign in as a different user and visit the same address. If it loads, you have an authorization problem. This is one of the most common serious issues in small applications, and it’s described in the OWASP Top 10 as broken access control.
Are admin functions protected on the server? Hiding an admin button isn’t protection. If the underlying address or API still works for a normal user, so does the admin function.
What happens when someone leaves? Can you remove a staff member’s access quickly and completely?
Are passwords handled properly? You should never be able to see a user’s password. If you can, stop and get help.

2. Personal and sensitive data

Do you know what personal information you collect? Names, emails, phone numbers, addresses, payment details, health information, documents. Write it down.
Do you need all of it? Data you never collect can’t be leaked.
Where is it stored, and who can reach it? Is the database accessible only to the application, or is it open to the internet? Are file uploads private, or stored in a publicly readable location?
Is it protected in transit? Every page should load over HTTPS, without exceptions or browser warnings.
Do you have a privacy policy that matches reality? In Canada, most private-sector organizations handling personal information in commercial activity are subject to PIPEDA or substantially similar provincial laws. Your policy should describe what you actually do.

3. Secrets and keys

Applications use secrets: database passwords, API keys for payment or email providers, and keys for AI services. AI-assisted projects frequently mishandle them, because the quickest way to make something work is to paste the key straight into the code.

Are any secrets in your source code? Search your project for strings like key, secret, token and password. Secrets belong in your hosting provider’s environment or secrets settings, not in files.
Has the code ever been in a public repository? If a secret was ever committed, assume it has been seen. Revoke and replace it — deleting the file is not enough, because version history remembers.
Are any secrets sent to the browser? Anything in front-end code can be read by anyone who visits your site.
Does each key have only the permissions it needs? A key that can only send email is far less dangerous than one that can manage your whole account.

4. Hosting and deployment

Do you know where it runs? Which provider, which account, and who has the login? If the only person with access is a former contractor, fix that first.
Is there a separation between testing and live? Changes should be tried somewhere other than the system customers use. Many AI-built applications are edited directly in production.
How do changes get deployed — and undone? If a change breaks something, can you return to the previous version in minutes? Do you know how?
Is your domain secure? Who controls the domain registration and DNS? Is two-factor authentication enabled on those accounts? Losing control of a domain is one of the most disruptive things that can happen to a small business.
Are error messages safe? When something fails, visitors should see a friendly message — not database names, file paths or code.

5. Backups and recovery

Backups are one of the most common gaps we expect to find in small applications, and one of the cheapest to fix.

Is the database backed up automatically? How often, and for how long are backups kept?
Have you ever restored one? A backup you have never restored is a hope, not a plan. Try restoring into a separate environment and time how long it takes.
What about uploaded files? Documents and images often live separately from the database and need their own backup.
How much data could you lose? If the last backup was 24 hours ago, can your business tolerate losing a day of orders or records?
Is the recovery process written down? In a crisis, a one-page instruction is worth far more than good intentions.

6. Performance and growth

You don’t need to design for a million users. You do need to know what happens at ten times your current usage.

Do lists and searches have limits? A page that loads every record at once is fine with fifty records and painful with fifty thousand. This is a common pattern in generated code.
Are there usage-based costs? AI APIs, serverless functions, databases and email services often charge per use. A runaway loop, a bot, or a popular week can produce a surprising bill. Set spending alerts and limits.
What happens under load or abuse? Can someone submit your forms thousands of times? Are there rate limits or bot protection on sign-up, sign-in and contact forms?

7. Maintainability

Could another developer take this over? Is the code in version control, with a readable structure and a short explanation of how to run it?
Are dependencies kept up to date? Most applications rely on dozens or hundreds of third-party packages. Some will have security fixes released after you launch.
Are there tests for the important rules? Particularly the rules about who can see and change what. Tests turn “we fixed it” into “we can prove it stays fixed”.
Do you understand the AI tool’s changes? When an AI assistant fixes one problem, it can quietly change something else. Reviewing what changed — not just whether the error went away — is a habit worth building.

8. Operations: when something goes wrong

Who would notice if the site went down? Ideally a simple availability check, not a customer.
Where are the logs, and do they contain anything they shouldn’t? Logs are invaluable for diagnosis but shouldn’t contain passwords, full card numbers or other sensitive data.
Who is responsible for security updates? “Nobody in particular” is a common, honest answer — and a risk.
Which outside services do you depend on? Payment, email, AI APIs, authentication. What happens if one is unavailable or changes its pricing?

A practical way to use this list

Don’t try to fix everything at once. Work through the list and mark each item as fine, not sure or needs work. Then prioritize:

Anything that could expose other people’s data — access control, secrets, public storage. Fix before inviting more users.
Anything that could lose data or lock you out — backups, domain and hosting access.
Everything else — performance, maintainability and monitoring, as part of normal improvement.

The “not sure” answers matter most. They’re where an experienced second opinion is usually most valuable, because the risk isn’t that you made a mistake — it’s that you can’t yet tell.

When to get an independent review

Consider an independent review if your application handles personal or financial information, if customers or staff will depend on it, if you’re about to invite significantly more users, or if you simply can’t answer several of the questions above with confidence.

A good review won’t make you feel foolish for using AI tools. It will tell you what’s already sound, what needs attention, and in what order — in language you can act on. That’s exactly what we do in an Independent Application Review. You can also see what a report looks like before getting in touch.

This article is general information, not advice about your specific situation. We review our articles periodically and update them when the facts change.