Before you launch
We built our app with AI. Is it safe to launch?
The hard part is that a working app and a safe app look identical from the outside. AI coding tools are good at producing software that runs. They are not asked, and do not answer, what else that software can reach.
This page is what we look for, in plain words, plus the four things our own scanner missed the first time we pointed it at a realistic codebase. We publish the misses because a security check you cannot audit is a security check you should not trust.
Our own receipts
What our own scanner missed
We built a test codebase with real flaws planted in it and ran our scanner over it. It produced 52 findings and missed four problems that were genuinely there. Three are now covered. One is not, and that one is listed here too.
A broken cipher, called from inside a function
Our scanner caught the import and missed the call, because the borrowed rule expected both to sit next to each other at the top of a file. Real code puts the call inside a function, where it can never sit beside the import.
A login secret written straight into the source
Missed, because the borrowed rule only matched when the code was written as a bare statement. Naming the middleware first, which is the ordinary way to write it, made the secret invisible to the check.
A cross-origin setting that reflects any origin, with credentials on
No borrowed rule covered it at all. We wrote one, deliberately narrow, so that a fixed allowed origin stays silent. Warning about a correct setting is how a scanner teaches people to ignore it.
A file-store rule leaving patient records open to anyone
Still not covered, and we are saying so rather than implying coverage. Those rules have no grammar our scanner can parse, and routed through a similar one the result cannot tell an open bucket from a deliberately public one. A check that cannot make that distinction would tell you a correct setting is a vulnerability.
The pattern in the first two is worth naming, because it is the reason borrowed rules give people false comfort. Both matched a tutorial and missed a codebase. They were anchored to where a line sits in a file rather than to what it does, so ordinary code slipped past them.
The checklist
What a review reads for
- Secrets committed anywhere in the repository, including its history
- Permissions wider than the feature actually needs
- Storage and database rules left open from the first day they were wired
- Login and session code that trusts a value instead of verifying it
- Every pinned dependency, checked against public vulnerability data
- The instruction files your AI tools read, since those steer future changes
The report says what we found, what we would fix first, and which checks could not run. A check that could not run is written as not measured, never as a pass.
Common questions
Plain answers
We built our app with AI. Is it safe to launch?
Probably not yet, and the reason is specific rather than general. AI coding tools produce working software with a small number of recurring gaps: a secret written into the source, a permission set wider than the feature needs, a storage rule that never got tightened after the demo. The app runs correctly, so nothing looks wrong. A review reads the code for those shapes before real customers arrive.
What actually goes wrong in an AI-built app?
The same handful of things, over and over. A key or token committed into the repository. Login code that trusts a value it should verify. A file store or database rule left open from the day it was first wired up. A cross-origin setting that reflects whatever origin asks. None of these break the app, which is exactly why they survive to launch.
How is this different from the app working fine in testing?
Testing asks whether the app does what you asked. A review asks what else it can do. Those are different questions and the second one is the one that matters once money or customer records are involved. An app can pass every test you wrote and still hold a key that lets anyone read the database.
Who checks an AI-built app before launch?
Usually nobody, because the people who built it with AI tools do not have a security engineer and the tools do not flag these gaps. That is the whole reason this service exists. We read the code you actually wrote, and we say plainly what we did not look at.
What do you actually run?
A static analysis pass over your source, a check of every pinned dependency against public vulnerability data, a scan for secrets committed anywhere in the history, and a read of the instruction files your AI tools follow. You get a written report naming what we found, what we could not measure, and what we would fix first.
What does it cost and how long does it take?
One week, one fixed fee, agreed on the free 30 minute call before any work starts. If you decide to build with us after the review, that fee comes off the quote.
What will you not do?
We do not hold your production data, your credentials, or your customer records. The review runs on a copy of the code and the copy is deleted when we deliver. We also do not certify anything. The report is findings for the owner, and it is not an assurance opinion for a third party.
If you want yours read
It starts with a free 30 minute call. If a review makes sense after that, it is one week at one fixed fee you hear on that call, and the fee comes off the quote if you decide to build with us afterwards.