Your AI-built app works. Here’s what it’s missing before real users

You described what you wanted, an AI tool wrote the code, and now the app works. That is a real achievement: not long ago it would have taken a team weeks. Whether you built it yourself or your team did, the next question is the same: is it ready for people who aren’t you?

Usually not yet. AI tools are very good at making things work on your screen. They are less reliable at the parts nobody sees in a demo, because nobody asked for them, and the app runs fine without them until the day it doesn’t. Here is what is usually missing, in plain words.

What’s usually missing

• Logins and permissions. A login proves who someone is; permissions decide what they can see and change. The common gap isn’t the login screen, it’s the second part: can one user see another user’s orders by changing a number in the web address? Try it.
• Secrets. Secrets are the passwords and keys your app uses to talk to other services, such as the AI provider or the payment system. If they’re written in the code, anyone who gets the code gets them too. They belong in environment variables: settings stored on the server, outside the code.
• Backups. A backup is a copy of your data you can bring back. Many hosting setups don’t make one by default. Check that backups exist, and restore one once: a backup you’ve never restored is a hope, not a backup.
• Error handling. When something fails, the app should show a clear message, keep the user’s work and record what happened. Without it, users see a blank page and you see nothing.
• Privacy. If you collect names, emails or anything personal, you need to know where it’s stored, who can read it and what you send to outside services, including the AI. Many countries have laws about this.
• Cost limits. Every AI request costs money. A bug that repeats itself in a loop, or a stranger who finds your form, can run up a bill overnight. Set spending caps with your providers, and limit how often one user can call the expensive parts.
• Tests. Tests are automatic checks that confirm the important parts still work after each change. Ask your AI tool to write them for the flows that matter most: signing up, paying, saving data.
• Monitoring. Monitoring tells you when the app is down, slow or throwing errors, before your users do. Even a simple uptime check and error alerts by email are a big step.
• Updates. Your app is built on dozens of libraries, pieces of code written by other people. They get security fixes. Someone needs to apply them and check that nothing broke.

A prioritized “before launch” list

You don’t have to do everything at once. This is the order we’d use, from “don’t launch without it” to “add it in the first weeks”.

1. Move secrets out of the code, and replace any key that was ever shared, pasted or published.
2. Check permissions: log in as two different users and confirm neither can see the other’s data.
3. Turn on backups, and restore one to prove it works.
4. Set cost limits on every paid service, the AI above all.
5. Handle errors on the main flows, with a message for the user and a record for you.
6. Add monitoring: uptime and error alerts, at minimum.
7. Write down what personal data you keep, where and why.
8. Add tests for the flows that would hurt most if they broke.
9. Plan updates: who checks for security fixes, and how often.

The first four protect people and money. The rest let you know when something goes wrong, and fix it calmly instead of in a panic.

When to get help

If your app handles payments, health or financial information, or data about children, or if a mistake would be expensive or embarrassing, have an experienced engineer review it before launch. Fixing these things now costs far less than fixing them after an incident. That is what our prototype to production service is for: keep what already works, and add what real users need.