Published July 12, 2026 · Kiyansh Group
An AI-generated app can look finished and still be one real user away from a data breach or a silent data-loss bug. The gap between demo and product is made of specific, missing things — and most of them a non-engineer can check without reading a line of code. Here are five tells and how to verify each one yourself.
Talk to us about staffing →The most common flaw in a generated app is that anyone who signs up can see everyone else's data. The login screen exists, but behind it the database hands out every row to any authenticated request. Authorization — the rules for who may read or change what — often isn't there at all, because the app was only ever tested with one account.
You can check this without an engineer. Create two accounts, put a distinct piece of data in each (a project named 'Alice-test' and one named 'Bob-test'), then open your browser's developer tools, go to the Network tab, and watch the requests as you load a page. If you can see the other account's data in a response, or if changing an ID in the address bar shows you someone else's records, the app has no real authorization and is not safe to launch.
If your app talks to Stripe, OpenAI, an email service, or any paid API, the key for that service must live on the server. AI builders frequently paste API keys straight into the frontend code, where anyone can copy them and run up your bill. The same goes for business rules — pricing, discounts, access tiers — that get enforced in the browser, where a user can simply turn them off.
To check for exposed secrets, open the app in a browser, right-click, choose 'View Page Source' or open the Sources tab in developer tools, and search (Ctrl+F) for 'key', 'secret', 'sk_', or 'api'. Anything that looks like a long random string sitting in that code is a leaked credential. For business logic, try to do something you shouldn't — apply an expired coupon, set a price to zero in the network request — and see if the server accepts it. If it does, the rule was never really enforced.
Migrations are versioned, repeatable instructions for changing the database structure. Without them, every schema change is a manual edit made by hand in a dashboard, which means changes can't be reviewed, can't be rolled back, and can't be reproduced on another environment. It's the difference between a database that evolves safely and one where a wrong click loses a column of customer data.
Ask your developer or the tool one question: 'Where are the migration files?' A production-ready project has a folder — often called migrations, prisma, or db — containing dated files that describe each schema change. If the answer is 'we just edit the tables directly in Supabase' or 'there aren't any,' the project has no safe way to change its own structure, and every future change is a gamble on live data.
In a demo, nothing goes wrong because you only click the happy path. In production, payments fail, networks drop, and users submit things you didn't expect. A production app catches those failures, shows the user something sensible, and records what happened so someone can investigate. A prototype usually just crashes to a blank white screen and leaves no trace.
You can test this in five minutes. Turn off your wifi mid-action, submit a form with garbage in every field, or double-click a 'pay' button, and watch what happens. If you get a blank page, a raw error dump, or the app silently does nothing, there's no error handling. Then ask: 'When a user hits an error, where does that get logged?' If there's no answer, no one will ever know your app is failing until customers stop coming back.
Tests are automated checks that confirm the important parts of the app still work after a change. Their absence isn't fatal on day one, but it guarantees that every future edit risks silently breaking something that used to work — and with AI-generated code, changes come fast and touch a lot at once.
Ask to see the test files, or ask 'what happens to the tests when we make a change?' A project with any test discipline has files ending in .test or .spec, or a folder named tests, and a command that runs them. If there are none, understand what you're accepting: every change to the app is unverified, and the way you'll find out something broke is a customer telling you.
Authentication, exposed secrets, and error handling are non-negotiable before real users touch the app — they cause breaches, surprise bills, and silent failures. Migrations and tests you can begin adding right after launch, but the longer you wait, the more expensive they get.
The first four, yes. Creating two accounts, opening developer tools, viewing page source, and trying to break a form are all things a careful non-engineer can do in under an hour. The fifth, tests, is a single question you ask your developer. None of it requires reading code.
Ask them to walk you through each of these five specifically, not in general terms. 'Fine for now' is reasonable for tests; it is not reasonable for auth or leaked API keys. The distinction matters, and a good engineer will tell you exactly which corners were cut and why.
If you've run these checks and something looks wrong — or you'd rather have someone read the code and tell you the truth — Kiyansh Group does production-readiness reviews and fixes what needs fixing.
Start a conversation →