Is Your AI‑Built App Ready for Customers? Check Before They Arrive

• A demo proves the paths you clicked, with one account. It doesn't prove what happens when strangers arrive with their own data.

• Six checks need no code reading, just two test accounts and an afternoon.

• If you only run one, run the first. OWASP ranks broken access control as the top web application risk, whether a person or an AI wrote the code.

• Some things a self-check can't settle: the data rules on the server, payment confirmation, sign-in flows and sensitive data. Those need someone who reads code.

• A failed check usually points to hardening, not a rebuild. Your prototype has already done the expensive part, which is finding out what customers want.

You built the first version yourself with an AI tool, and real customers are about to log in. Maybe it was Lovable, Bolt, v0, Replit or Cursor. Maybe one customer has already paid, or an investor has asked for a look. The app works when you demo it, and you still can't tell whether the code underneath is a foundation or a liability.

That doubt is reasonable. It's easy to assume that if it runs, it works. A demo proves the paths you clicked through, with one account, on your own laptop. It doesn't prove what happens when forty strangers sign up with their own data and one gets curious about what else they can reach.

So is your AI-built app ready for customers? Often it's closer than the horror stories suggest. Plenty of AI-built prototypes are worth keeping, because they've already answered the hardest question in any product: whether anyone wants it. You can learn a lot about the rest without reading a line of code.

Set aside an afternoon. Create two test accounts that belong to two pretend customers, A and B, and sign in to each in a different browser so you're logged in as both at once. Most of the checks below use that setup.

1. Can one customer see another customer's data?

Sign in as A and open something that belongs to A: an order, a booking, a profile. Copy the address from the browser bar and paste it into B's browser. If B can see that record, or change it, stop and fix it before anything else.

Then try the less obvious doors. Change the number at the end of the address. Search for A's name from B's account. A hidden button isn't a rule. OWASP's 2025 Top Ten keeps broken access control in first place, reports that 100% of the applications tested had some form of it, and says access control only works when it's enforced in trusted server-side code, where a user can't tamper with the check. That's true of hand-written software too. AI tools just make it easy to ship a screen that hides data without a rule that protects it.

If you only run one check, make it this one. The others matter, but a customer seeing another customer's records is the failure you can't take back.

2. Does the business own every account the app depends on?

List every service the app touches: the AI builder itself, the code repository, hosting, the database, the domain, email sending, payments, file storage and analytics. Next to each, write whose name and card it's under and who can sign in as an administrator.

A good answer is boring: everything sits in the company's name and at least two people can recover each account. A bad answer is a database in a freelancer's account, or a domain registered by whoever helped you set it up. Then ask one more question: if the database vanished tonight, where's the backup, and has anyone ever restored one?

3. Is any secret key reaching the browser?

Your app talks to other services using keys. Some are meant to be public. Others can do anything and have to stay on a server. If your app runs on Supabase, which Lovable can connect to as an app's backend, Supabase's API key documentation spells out the difference. Its publishable key is safe to expose because it only reaches what Row Level Security allows. Its secret key bypasses every Row Level Security policy and should never be put in a browser, a shipped app or source control.

You can check this without reading code. Ask the tool, or whoever built it with you, to list every key the app uses, where each one is stored and whether it ever reaches the browser. If the database has row-level rules, ask to see that every table has them switched on. “I'm not sure” is a finding, not a failure. It goes on the specialist's list.

4. What happens when two people do the same thing at once?

Pick the action where a collision would hurt: booking the last slot, claiming the same job, redeeming one voucher, paying an invoice. Have A and B do it at the same moment, counting down out loud if you have to. Then double-click the pay or submit button on purpose.

A good result is that one person wins and the other gets a clear message. A bad result is two bookings for one slot, two charges, or a record that ends up half one person's and half the other's. A demo with one user will never find this.

5. Can anyone explain what was generated?

Ask three plain questions. How does sign-in work? Where is a payment confirmed as paid? What happens when an email fails to send? You don't need to follow every detail. You need someone, whether a developer friend, the freelancer who helped or you working with the tool, to give an answer that's specific and doesn't change when you ask twice.

If the only honest answer is “the AI wrote it and it works”, nobody owns the logic your customers will depend on. That's fixable. It means part of the review is writing down what the app actually does.

6. Can you change something without breaking something else?

Think back over the last few changes. Did fixing one screen break another? Do changes go straight to the live app, or is there a separate copy where you try them first? If a change goes wrong, can you put the previous version back quickly, without editing customer data by hand?

A prototype can get away with editing live. A product with paying customers can't. A test copy and a way to roll back are the cheapest insurance on this list.

The six checks find the obvious holes. They can't confirm that the rules underneath are right, and that's where generated code tends to look fine and fail quietly. In Veracode's 2025 GenAI Code Security Report, which tested more than 100 language models on 80 coding tasks, the models introduced a vulnerability from the OWASP Top 10 in 45 percent of test cases. Veracode also found the models were getting better at writing code that works, but not at writing code that's secure.

So a few things need a person who reads code:

• The data rules themselves. Whether every table and request checks who's asking, not just the screens you tested.

• Payments. Whether the app waits for the payment provider to confirm a payment, or trusts the browser's word that it went through.

• Sign-in and password reset. The flows attackers try first and demos rarely exercise.

• Sensitive or regulated data. Health, financial or children's information brings obligations no checklist can settle.

• Dependencies and running costs. Outdated libraries with known flaws, and database or AI usage that gets expensive once real traffic arrives.

Ask for a bounded review with a written result: what's sound, what's risky, what to fix first and why. This is close to how we run a software build second opinion. The report carries a list of what to keep next to the list of what to fix, because a review that only finds problems pushes you towards a rebuild you may not need.

With your six answers and a specialist's findings, the decision usually lands in one of three places. Rebuild is the right answer less often than the internet suggests, and it's worth noticing how much of the advice to rebuild comes from firms that sell rebuilds.

Keep

The checks pass, someone can explain how the app works and the specialist's findings are ordinary defects. Keep building, with a review on any change that touches sign-in, payments or customer data.

Harden

Some checks fail, but the failures are specific: missing data rules, a secret key in the wrong place, accounts in the wrong names, no test copy, no way back from a bad release. Fix them in a set order, data access first. Hardening isn't a consolation prize. It keeps the screens, the flows and everything customers have validated, and changes only what's unsafe.

Rebuild

Rebuild when the foundation can't hold the business, not when the code is merely messy. The data model can't represent how you actually sell, say one user per account when your customers are teams. Every fix breaks two other things and nobody can explain why. Or sensitive data sits in a shape that can't be made safe without starting again. Even then the prototype isn't wasted. Its screens, flows and customer feedback become the specification for the rebuild.

If your first version lives on a no-code platform rather than in code you own, the signals are different. We covered those in when to move from no-code to custom development.

Illustrative example. This scenario was made up for this article. It doesn't describe a client, a real app or a measured result.

A founder who used to manage a fitness studio builds a class-booking app with an AI app builder. Members book and pay for classes, and studio staff manage the timetable. Twelve independent studios are using it on a free pilot, and the first paid contract starts next month. She runs the six checks over a weekend.

Five checks failed and one is unknown, which feels like a disaster on a Saturday night. It isn't. None of the failures sits in the parts her studios care about: the booking flow, the timetable and the reminders. She hardens rather than rebuilds, and the member list gets fixed first.

Create two test accounts and try to see one from the other. It's a short job, and it'll tell you more about your app than any amount of reading about vibe coding. Then take the product readiness assessment and answer Not sure wherever you couldn't confirm something. Those answers are the brief for whoever reviews the code.