Built an app with AI? What to check before real customers use it

Why this matters

"Vibe coding" means building software by describing what you want to an AI tool and accepting what it produces. It is a fast way to test an idea. The catch is that a prototype that works in a demo is not the same as software that is safe with customer data, money and growth.

The good news is that a prototype which proved the idea has already done its most important job. The next step is making it sturdy.

The pre-launch checklist

1. Access and permissions

• Can a logged-in customer see only their own data? Try changing an ID in the web address and see what appears.
• Are admin pages protected, not just hidden?
• Is there rate limiting on logins and forms?

2. Secrets and keys

• Are API keys, database passwords and payment keys kept out of the code and out of anything sent to the browser?
• Have any keys ever been committed to a code repository? If so, change them.
• Does each key have only the permissions it needs?

3. Personal data

• What personal data are you collecting, and do you need all of it?
• Is it encrypted in transit and protected at rest?
• Do you have a privacy notice that matches what the app actually does?
• Could you delete a customer's data if they asked?

4. Payments

• Are payments handled by an established provider rather than by your own code?
• Do you check payment confirmations on the server rather than trusting the browser?
• What happens if a payment succeeds but your app crashes before recording it?

5. Reliability and backups

• Is the database backed up automatically, and have you tested restoring it?
• What happens when a connected service is slow or down?
• Will you know when something breaks, before a customer tells you?

6. Costs at scale

• Do any services charge per request, per user or per AI call?
• What would the monthly bill be at ten times today's usage?
• Are there limits or alerts to stop a runaway bill?

7. Ownership and support

• Can someone other than the original builder understand and change the code?
• Who fixes it at 9am on a Monday when it stops working?
• Do you own the code, the hosting account and the domain?

Common problems we see

These are typical of quickly generated code and are usually fixable:

• Security checks done only in the browser, which anyone can bypass.
• Keys or passwords visible in the front-end code.
• One large file doing everything, which becomes hard to change safely.
• No tests, so every change risks breaking something else.
• Several half-finished approaches to the same feature left in the code.

Rescue, rebuild or carry on?

Not every prototype needs rebuilding. Often the right answer is to keep what works, fix the risky parts, add tests around the important features and put proper hosting and monitoring in place. Sometimes a clean rebuild using the prototype as the specification is quicker. An experienced developer can usually tell you which within a day or two of looking at it.

FiveW helps businesses make AI-built prototypes stable, secure and supportable. If you are not sure where you stand, tell us what you have built and we will give you an honest view.