Ask your AI if your app is secure. Here are the questions.
Twelve prompts to run against the AI that built your app, phrased so it has to show you rather than reassure you.
Free, no sign-up, and it takes an evening. Ask them in order. The first three find something in most AI-built apps, and the answers are yours whether or not you ever talk to us.
The questions
Grouped the way a production audit groups them. Paste each one as written; the brackets are for you to fill in. Every one asks for a place, a name, a date or a list, never an opinion, which is the only reason they work.
Security
- 01
List every API key, token or secret that ends up in the code the browser downloads, or anywhere in the commit history. For each one, show me the file and the line.
A real answer File paths and line numbers, or a clear statement that the client bundle was searched and what was searched for. A key for a paid service in the browser bundle is the most common first finding.
If it just says yes Then ask: search the built output and the git history, not just the source, and show me the search you ran.
- 02
Show me the database access rules. Is row-level security on for every table that holds user data? List the tables where it is off, and any place the service-role key is used from the client.
A real answer Table names, the policies on each, and the exact spots the privileged key is used. In apps built on Supabase or Firebase this is where the database turns out to answer anyone who asks.
If it just says yes Then ask: for each table, show me the policy text. If a table has no policy, say so.
- 03
List every route that reads or changes a record. For each one, show me where it checks that the record belongs to the user making the request, not just that the user is logged in.
A real answer A route-by-route list, and for each a line of code doing the ownership check. Routes that only check for a session are the finding: change one number in the address bar and you are editing someone else's order.
If it just says yes Then ask: pick the route for [your most important record] and walk me through what stops another signed-in user from opening it.
- 04
Which public endpoints have no rate limit? Which ones accept input that is not validated before it reaches the database, or a paid API?
A real answer Two short lists, with the endpoints named. The one to look for is the endpoint that calls a paid model or provider with no cap: one script and you wake up to an invoice.
If it just says yes Then ask: show me the middleware or code that applies the limit, and which routes it is attached to.
Business logic and data
- 05
Where are the backups, how often do they run, and when was the last time one was actually restored? What happened when it was?
A real answer A location, a schedule, and a date with an outcome. 'Backups are configured' is not an answer; a restore that has never been tried is a backup on paper.
If it just says yes Then ask: walk me through restoring yesterday's backup to a fresh database, step by step, and tell me what would be lost.
- 06
Show me what happens if the same payment request, or the same webhook, arrives twice.
A real answer The code that makes a repeat safe: a stored idempotency key, a check before a charge, a webhook handler that ignores what it has already seen. Without it, a flaky connection double-charges a card or fulfils an order twice.
If it just says yes Then ask: show me the exact line that would stop a second identical request from charging again.
Reliability and deployment
- 07
What happens when an error is thrown inside [the core workflow]? Where is it caught, where is it logged, and who is told?
A real answer A path through the code, a log destination, and an alert that reaches a person. Errors that are caught and silently swallowed are the finding: the app looks fine while something is quietly failing.
If it just says yes Then ask: show me every catch block in [the core workflow] and what each one does with the error.
- 08
Are development, staging and production separate, each with its own database, config and secrets? Show me the configuration for each.
A real answer Three environments you can point at, with different credentials. One database shared between testing and real users, or one set of secrets for everything, is the finding.
If it just says yes Then ask: show me where the production database URL is set, and confirm nothing else uses it.
Code, tests and dependencies
- 09
Which flows have automated tests: signup, checkout, [the core workflow]? Show me the test files and what each one actually checks.
A real answer File names and a plain description of what each test proves. Tests exist in most AI-built apps; tests covering the flows that make money are rarer.
If it just says yes Then ask: run the tests and show me the output. Then show me the test for [the flow that makes you money].
- 10
List every dependency. Which ones have not been updated in over a year, which have known vulnerabilities, and which do not exist on the package registry at all?
A real answer Three lists. The third is real: AI tools sometimes import packages that never existed, and a name that does not resolve is an opening for anyone who registers it.
If it just says yes Then ask: run the dependency audit tool for this project and show me the raw output.
Performance and cost
- 11
What stops the bill for [the AI, maps or email provider] from running to any size? Show me the spending caps and the alerts, and where they are set.
A real answer A cap in the provider's dashboard or in code, and an alert that fires before the bill surprises you. If the only limit is the card on file, that is the finding.
If it just says yes Then ask: what is the most this app could spend on [the provider] in one day if someone called the endpoint in a loop?
Handoff
- 12
If we had to move off [Lovable, Replit or Bolt] hosting tomorrow, what would it take? What is tied to the platform, and what would have to be rewritten?
A real answer A list of what is portable and what is not: the database, the auth, the file storage, the deploy. Knowing the answer is not the same as needing to leave; it is knowing the app is yours.
If it just says yes Then ask: show me every place the code depends on something only this platform provides.
What this list cannot do
Run the twelve and you will know more about your app than most founders do about theirs. Three things it still leaves open, said plainly because a page whose whole point is 'verify, don't trust' should be honest about its own edges.
-
It is not the full list
These are twelve of the checks a production audit runs, chosen because a founder can run them alone. The full list is longer, and the questions that matter most for your app depend on where it is headed: an investor review and a first big client need different things checked first.
-
The AI is reviewing its own work
Asked the right way it will find real things, and this page is about asking the right way. It is still the same tool checking what the same tool built. An independent pair of eyes finds the questions nobody knew to ask.
-
'No finding' and 'didn't look' are not the same thing
When your AI cannot answer one of these, that is not a pass. Write it down as unverified and keep going. The list of what could not be checked is as useful as the list of what was found.
Then the other half: what you never thought to ask
The twelve above go deep. Each one is the exact prompt, what a real answer looks like, and the follow-up for when you get a confident one. They cover six areas and lean on security, because that is where damage arrives fastest.
The checklist does the opposite job. It is the surface rather than the depth: 34 questions across all seven areas, so you can see what you have not asked about at all. The problems that end up costing founders are rarely the ones they were already worried about.
It is still only the part you can ask. Most of what an audit examines cannot be reached by asking, because it needs the code, the database and the dashboards in front of somebody, and no list tells you whether the answers coming back are true.
A PDF you can hand to whoever is building. No sequence, no follow-up unless you ask for one.
Want it checked properly?
That is the prototype-to-production audit. It runs the checklist and a great deal more that no question can reach, in order, with the evidence written down and a plain statement of what could not be verified. Bring what the twelve found, or the repository, and we will tell you which level fits.
Free, and nothing to prepare. Pick a time that suits you.
- Phone / WhatsApp
- +971 58 502 0610
- [email protected]