Nine things to checkbefore your app meets real users.
These are the places an AI-built app breaks first. Each one lists what goes wrong and the single test that tells you whether it is wrong in your app. Run them yourself. Nothing here depends on hiring me.
- 01
Auth and authorization enforced on the server
The app hides the button, but the endpoint behind it still answers. Hiding a control in the browser is a design choice, not a permission check. This is the single most common hole in an app assembled quickly, because the visible behaviour looks correct in every demo.
Test itSign in as an ordinary user. Call the API directly with that session and ask for a record belonging to someone else. If it comes back, every user can read every record.
- 02
Secrets out of the client bundle
An API key that reaches the browser is public. Scrapers find keys in shipped JavaScript within hours, and the bill lands on you. A key restricted to your domain slows this down but does not stop it, because the restriction is a header anyone can send.
Test itOpen the deployed site, save the JavaScript it loads, and search that text for your key prefixes. Anything you find there is already public. Move the call to a server route and rotate the key.
- 03
Rate limits on every public endpoint
An unauthenticated endpoint that costs money per call is an open tab in your name. This includes anything that reaches a model, sends mail, or writes to your database. Without a limit, one script can spend a month of budget in an afternoon.
Test itSend a hundred requests to your most expensive public endpoint in a loop. If none of them are rejected, there is no limit. Add a per-address limit and a hard daily cap at the provider.
- 04
Webhook signatures verified
Payment and messaging providers sign their callbacks. Code that skips the signature check will accept a forged callback from anyone who knows the URL. That means a stranger can mark an order paid without paying.
Test itPost a hand-written body to your webhook URL with no signature header. If the app processes it, the check is missing or is being skipped when the header is absent.
- 05
N+1 queries and missing indexes
A list page that runs one query per row is fine with ten rows and unusable with ten thousand. It usually passes review because the seed data is small. The same is true of a query filtering on a column with no index.
Test itLoad your busiest list page and count the queries the request makes. If the count grows with the number of rows, it is an N+1. Then check that every column you filter or sort on has an index.
- 06
Backups with a restore drill
A backup you have never restored is a belief, not a backup. Silent failures are normal: the job stops, the bucket fills, the format changes. Nobody notices until the day it matters.
Test itRestore last night's backup into a scratch database and run the app against it. Write down how long the restore took. That number is your real recovery time.
- 07
Error tracking and alerting
If your first report of an outage is a customer, you do not have monitoring. Logs nobody reads are not monitoring either. Errors swallowed by a catch block are invisible twice over.
Test itDeliberately throw an error in production. If nothing reaches you within five minutes, the alerting path is broken. Then grep the code for empty catch blocks, which hide the errors you most need to see.
- 08
Dependency and security updates
Applications built quickly tend to pin nothing and update nothing. Months later the dependency tree carries known vulnerabilities, and the upgrade that fixes them is now a large one because so many versions have passed.
Test itRun your package manager's audit command and count the high and critical findings. Then check whether anything at all is scheduled to update them. Usually nothing is.
- 09
A runbook and an off switch
When the app misbehaves at 9pm, somebody needs to know how to turn the broken part off without redeploying. Without that, the only options are to leave it running or take the whole system down.
Test itAsk whoever is on call to disable one feature and restart the app, using only written instructions. If they cannot, write the runbook. Every risky feature should sit behind a flag you can flip.
Want it as a page you can hand to a developer?
Same nine checks, one page, printable. Put your email in and it downloads. I will send you a note when I write something worth reading, and nothing else. Unsubscribe in one click.
Found one you cannot answer?
Work down the list in order
The order above is the order I fix them in: the ones that leak data or money first, the ones that cost you a night of sleep later. Nothing on this list needs me.
Fifteen minutes, no charge
Bring the app or the repo and the item you got stuck on. I will tell you whether it is as bad as it looks and what I would do first.
Book a 15-minute fit callFifteen minutes to find out if I am the right person.
Bring the app, the repo, or the check you could not answer. No deck, no pitch.