Check your app before other people use it

What you need first

Know what your app holds. The risk follows the data, not the number of pages.

• A list of what you store about people — names, phone numbers, addresses.
• Which screens should be private.
• Any keys you have pasted in, and where you pasted them.

01 · Run the standard check

Nine checks run over your source and your built result, and they run before every publish. They cost no credits. Two of them look at the data rules, which is where a real leak usually comes from.

02 · Read the findings, not just the count

Each finding names the file and says what to change. A count on its own tells you nothing about whether tonight's launch is safe. Two minutes reading is worth more than any summary.

03 · Run the deeper scan when it matters

The deeper scan reads your code with an AI and looks for the things a rule cannot describe. It costs 2 credits. The first scan on a project is free, a scan that finds nothing is free, and a scan that fails to finish is free.

04 · Look at the suggested fix before applying it

Fixes are suggested, never applied for you. You see the exact before and after and press the button yourself. If the file has changed since, the suggestion is refused rather than forced in.

05 · Rescan instead of assuming

A finding is not removed from the list when a fix is applied. Whether it is really gone is something only a fresh scan can say. A clean rescan costs nothing.

If you get stuck

I dismissed a finding and I am still blocked. Dismissing hides a finding from your list. It is not counted as fixed, and the publish gate still counts it. The screen tells you how many are hidden.

Is the AI making findings up? A finding is kept only when the evidence it quotes is really in that file. Ones that cannot be confirmed are dropped before you see them.

How often should I run the deeper scan? Before you open to the public, and again after any change to logins, payments or who can read what. Not after every wording tweak.