Checklists and deep dives you can run yourself
The same material we work from when we audit an AI-built app: what to check, how to prove it passes, and what the answer means. No email gate, no signup - take them and use them.
What is in here
Pick the one that matches the question you have today
Each is written to be used once and then re-used: a checklist you re-run before every launch, a playbook you follow pass by pass, a framework you apply to a decision, and a model you keep in a spreadsheet.
- Checklist
The 40-point production readiness checklist
Forty checks that decide whether your AI-built app survives its first real users. Every one is written so it can pass or fail, with a line on how to prove which.
What it covers
- 40 numbered checks across eight areas, each with a one-line verification step
- Severity ratings so you know which failures actually block a launch
- The failure modes we see most often in Lovable, Replit, Base44 and Claude Code projects
- A scoring method and what to do with the result
Who it is for: Founders and small teams two to four weeks away from putting an AI-built app in front of paying users.
9 sections · 9 min readRead the guide - Playbook
The AI-built app security audit guide
The order we work in when we audit an app that came out of Lovable, Replit, Base44 or Claude Code - with the commands and queries we actually run at each pass.
What it covers
- Nine passes in the order that finds the worst problems first
- Copy-and-run commands, SQL and curl probes for each pass
- The specific patterns AI builders generate that fail - permissive policies, client-side keys, unsigned webhooks
- A severity rubric and the order to fix in
Who it is for: Technical founders and engineers who can run a shell command and a SQL query, auditing an app they own.
11 sections · 12 min readRead the guide - Decision guide
Choosing your production stack after the builder
A framework for deciding where your app should actually run once the builder's hosting stops fitting - including the case against each option, which is the half most comparisons leave out.
What it covers
- Five questions that decide the answer before you look at any provider
- Vercel, Fly.io, Railway, AWS and GCP - strengths, real cost, and when each is wrong
- Why the database decision matters more than the compute decision
- The order to migrate in, and five ways this goes badly
Who it is for: Founders and technical leads whose builder hosting is starting to cost too much, constrain the product, or fail a customer's security review.
8 sections · 9 min readRead the guide - Model
Cost modelling: what your app will really cost at 10x and 100x
How to build a cost model that survives growth: the demand drivers, the line items people forget, and the traps that turn a sixty dollar bill into six thousand without the product changing.
What it covers
- A four-step model you can build in a spreadsheet in an afternoon
- Every line item, including the ones that are zero today and dominant at 100x
- A worked example at 1x, 10x and 100x showing how the shape of the bill changes
- Break-even maths for whether a migration pays for itself, and the controls to add first
Who it is for: Founders and operators who need to know whether the unit economics survive the next order of magnitude, and which line item breaks first.
8 sections · 9 min readRead the guide
Built to be worked through, not skimmed
A first pass through the checklist takes most teams a working day. Every later pass takes about ninety minutes, which is the point of writing checks down.
- 1
Read the checks, not the prose
Every guide is built around items you can pass or fail.
- 2
Run them against staging
The commands and queries are safe to run against an environment you own.
- 3
Write down the unknowns
The items you cannot answer are the real output of a first pass.
What these guides keep finding
Six things we run into again and again in apps built with Lovable, Replit, Base44, Bubble and Claude Code. None of them are exotic, and all of them are cheap to fix before launch and expensive afterwards.
- 01
Row-level security written for the demo
A policy that reads correctly for the signed-in user and also returns every other user's rows.
- 02
A privileged key in the client bundle
Service-role and admin keys reach browser code through a public environment prefix, where they bypass every access rule the database has.
- 03
One database for development and production
Test actions mutate real customer records, and there is no environment where anything can safely be tried first.
- 04
A development server facing the internet
Single-process, debug-enabled, and explicitly documented as unsafe to expose - but it is what the app was started with and nothing forced a change.
- 05
Backups that have never been restored
Snapshots exist and nobody has ever run one back. An untested restore is a plan, not a backup.
- 06
Queries with no index and no limit
Instant on a hundred rows, a timeout at a hundred thousand.
Every one of these has a check and a verification step in the guides above. Start with the 40-point checklist if you are not sure which applies to you.
Every guide maps to something we do
The guides are the work, written down. If you would rather hand it to someone, these are the four ways that happens - and the first conversation costs nothing.
Not sure which of these you need?
Send us the app and we will tell you which findings apply to you, on a free call.