Build check
Check your build in two minutes
See exactly what’s missing, what’s at risk, and what nobody on your team can answer, with a free graded report on your app. Just answer 15 quick, direct questions. It takes about two minutes, and “not sure” is a valid answer.
Coverage
What the check covers
The same five areas a paid audit works through, in the same order, because each one depends on the one before it. There is no point hardening a login on code you cannot move.
Day 1
Access and ownership
Everything else on this list depends on this one. If the code lives inside a platform account rather than a repository your company owns, nothing can be moved, audited or handed to another team without the platform's permission. The same question applies to people: an app only one person can deploy is a holiday away from an outage nobody else can end. The third piece is the quiet one, the outside services the app leans on, each of them a bill that can lapse and a door somebody else controls.
- Where the source code actually lives
- Who besides its builder can ship a change
- Which outside services the app depends on, and who pays for them
Day 2
Security and data
The most common critical finding in an AI-built app is a key or a password shipped to the browser, where anyone who opens the app can read it. It has usually been true since launch and nobody has looked. The second is a database that answers questions it should refuse: these platforms provision tables with access rules switched off, and hiding a button in the interface does not stop anyone asking the database directly. The third is what your users upload. These platforms create file storage open and leave it that way, so the invoice, the identity document and the signed contract can be opened by anyone who has the link, and links get passed around.
- Keys and passwords readable in the browser
- Access rules enforced by the database, not the interface
- Whether uploaded files can be opened by anyone with the link
Day 3
Logging in and getting at data
Access control fails in ordinary ways rather than clever ones: a private page nobody ever checked, reachable by anyone who pastes the address. Search engines find those by accident. Account recovery belongs here too, because a reset flow nobody built turns every forgotten password into a manual job, and manual resets are how accounts get handed to the wrong person. Then what an account can reach once it is inside, because the usual leak is not an attacker but a normal user opening a page that was never meant for them, and the separation between one customer's data and another's, which everybody assumes and almost nobody has tested.
- Private pages that actually stop a logged-out visitor
- Password reset that does not need you
- Normal accounts kept out of admin pages and other people's records
- Tested separation between customers
Day 4
Shipping changes and getting back up
A test copy of the app is what makes it safe to change anything at all. Without one your users are the testing environment and every fix is a live experiment on the people paying you. Backups are the other half, and they fail quietly: one nobody has ever restored is a belief rather than a backup, and the difference only becomes apparent on the worst day of the year. The last question is speed, because how long it takes to put a broken change back is exactly how long the outage lasts.
- Somewhere to be wrong before users see it
- A backup somebody has actually restored
- How fast a bad change can be undone
Day 5
The state of the code
This is where an AI-built app charges you later rather than immediately. When nobody can say what a change will break, small requests stop being small, and the expense is not the change itself but the week after it. Underneath that sits the question of whether anyone senior has ever looked at how the thing is put together. Structural decisions made by whoever happened to be available, or by a tool with no view of where the product is going, are cheap to make and expensive to unpick.
- Whether anyone can predict what a change breaks
- Whether a senior engineer has reviewed the structure
How your answers are graded
Four grades, the same ones our written audits use, applied here to what you tell us rather than to what we have read in your code. The fourth is the one worth understanding before you start.
- CriticalLive now and cheap to exploit. These are the findings we phone about on the day we find them.
- HighNot an emergency this morning, but the thing that turns an incident into a crisis.
- MediumReal, and worth working through in the ordinary run of things.
- UnknownNobody could answer. Counted apart from what is missing, because an unverified control is not a working one, and this is usually the biggest number on the board.
What a result looks like
Production Readiness Check
- Database credentials exposed on the main branchCritical
- Production code that was never committed to the repositoryCritical
- No password reset, and no second step at login, so a stolen password is full accessHigh
- Features that only saved data on the user's own computer, so it vanished on another deviceHigh
Findings from the Lovable audit described on the main page, graded on the scale above. That one took five days inside the code. Yours takes two minutes and is built from your own answers, on the same scale, which is as close as a questionnaire gets.
The questions
All fifteen, and why each one is on the list
Published in full. The questions were never the valuable part: knowing what your own answers add up to is, and that is what the check does with them.
Day 1
Is your source code in a repository your company owns, not only inside the platform account?
Ownership decides whether anything else on this list can be fixed at all. Code you cannot move is code you cannot repair, migrate, or hand to another team.
Could someone other than the person who built it deploy a change tomorrow?
One person who can deploy is one holiday away from an outage nobody else is able to end.
Can you name every outside service the app depends on, and who pays for each one?
You cannot secure, budget for, or replace a dependency nobody has ever written down.
Day 2
Are you certain no keys or passwords are sitting in the part of the app that runs in the browser?
Anything shipped to the browser is public, whatever it looks like in the editor.
Does your database refuse requests it should not answer, enforced at the database itself and not just hidden in the interface?
An interface is a suggestion. The database is the only place a rule is actually enforced.
Do the files your users upload stay private, even from someone who has the link?
Users upload the documents they would never publish. These platforms create file storage open, and nobody goes back to close it.
Day 3
If someone who is not logged in pastes the address of a private page, are they reliably stopped?
Most access-control failures are not clever attacks. They are a page somebody forgot to check.
Can a user reset a forgotten password without anyone touching the database?
Account recovery is part of the security model, not a convenience bolted on afterwards.
Is a normal user account actually blocked from admin pages and from other people's records?
The usual leak inside an app is not an attacker. It is a normal user opening a page that was never meant for them.
Has anyone actually tested that one customer cannot reach another customer's data?
Separation between customers is assumed by everyone and verified by almost nobody.
Day 4
Is there a test copy of the app where changes are tried before your users see them?
Somewhere safe to be wrong is what makes it safe to change anything.
Has anyone ever restored the database from a backup and confirmed it worked?
Backups fail quietly. The only proof one works is having restored it.
If a change breaks the live app, can you put it back the way it was in minutes?
How fast you can undo a change decides how bad a bad change is allowed to get.
Day 5
When you ask for a change, does anyone know what else it might break?
Structure is what keeps small changes small. Without it every request is a gamble.
Has a senior engineer who is not building it ever reviewed how it is put together?
A second opinion is cheapest before the thing is built, and impossible to backdate.
Questions
Questions about checking an AI-built app
Production readiness is less about the features working and more about what happens when something goes wrong. Can you restore the database, undo a bad deploy, stop a logged-out visitor reaching a private page, and be sure a normal user cannot open an admin page? An app can run perfectly every day and still fail all four.
Not by default. The recurring failures are keys and passwords visible to anyone who opens the app in a browser, databases that answer requests they should refuse, and normal accounts that can open admin pages nobody meant to leave open. None are hard to fix once found, but they stay invisible until somebody deliberately looks for them.
Start with the four that cannot be undone afterwards: the code is in a repository your company owns, no secrets are shipped to the browser, the database enforces its own access rules, and a backup has actually been restored at least once. Everything else can be fixed later without losing anything.
No. Every question is written to be answerable by whoever runs the product, and “not sure” is a real answer that counts towards your result rather than being skipped. If a question needs a developer to answer it, that gap is itself the finding, and the result says so.
Nothing you have not asked for. The result is shown on screen for free and yours to act on with your own team. You can take the full checklist by email, or book a call if the result suggests an audit is worth doing. If it does not, we say so.