Skip to content
Guide

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.

Go to the questions Or have it audited
Question 01, asked the usual way Fig. 1
You

Is my app secure?

Your AI

Yes. Your app follows security best practices and is ready for users.

What that yes proves

Nothing yet. It answered about the code it could see. The twelve prompts below make it show you instead.

Ask it to show you, not to reassure you. The better prompt
Free, no sign-up. Paste, run, read. Show me, not tell me. 12 prompts / 6 areas / one evening

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

  1. Prompt 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.

  2. Prompt 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.

  3. Prompt 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.

  4. Prompt 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

  1. Prompt 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.

  2. Prompt 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

  1. Prompt 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.

  2. Prompt 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

  1. Prompt 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].

  2. Prompt 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

  1. Prompt 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

  1. Prompt 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.

  • 01

    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.

  • 02

    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.

  • 03

    Silence is not a clean answer

    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. The checklist does the opposite job: it is the surface rather than the depth, every area, so you can see what you have not asked about at all.

Questions

questions

Areas

areas, in the order a miss hurts

Follow-ups
0

sales sequences after it

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.

Sending this also puts you on my email list: what audits turn up, and when the course opens. A few times a year at most, and one click stops it for good.

I keep your name and email to send the checklist and to write to you, and delete them after 24 months. Nobody else sees them, ever. Privacy notice.

No list beyond this. Leave whenever you like.

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.

What the audit covers

We use what you send only to reply and, if we work together, to keep a record of it. Privacy notice.