What a production readiness audit of an AI-built app actually checks

A production readiness audit reads your code, database and hosting, scores the app across twelve domains, and tells you in writing what will fail when real users, money and data arrive, in what order to fix it, and what the fix costs.

What is a production readiness audit, in plain words?

An app built with Lovable, Bolt, Cursor, Replit or v0 can look finished long before it is safe. The screens work. The demo goes well. What you cannot see from the screens is whether one customer can read another customer's records, whether your keys are visible in the browser, or whether there is a working backup.

An audit is a senior engineer reading the parts you cannot see. We do not click through the app and write opinions. We read the repository, the database rules, the hosting setup and the deploy process, then check each of twelve domains against a fixed list of questions. A "no" to any question is a finding.

Our audit takes five working days and costs $1,500. It is the first step of our AI product rescue work, and the checklist behind it is public on our production readiness checklist page.

Which twelve areas does the audit score?

Architecture, authentication, authorisation, data, security, reliability, testing, performance, AI features, observability, deployment and cost. Each gets a score out of 10 and a one-line finding. Below, they are grouped by the question they answer for you as an owner.

Is the app built in a way that can be maintained?

Architecture. Can the system be drawn on one page? Are the boundaries between the interface, the server and the database clear? AI tools often write the same piece of business logic in several places, so a price rule or a discount might live in three files. Change one and the others quietly disagree.

Deployment. Can you undo a bad update in one step? Are your test and live environments separate, each with its own keys? Does every change pass through an automated build before it goes live? If the answer is no, every release is a small gamble.

Performance. We look at the slowest database queries and at patterns that are fine for ten users and fail for a thousand. One common example is a page that asks the database a separate question for every row it shows, instead of one question for all of them.

Who can see and change what?

Authentication is how the app knows who someone is. We check that sessions expire and can be cancelled, that passwords and sign-in are handled by a proven provider, and that account recovery does not open a hole.

Authorisation is what each person is allowed to do once signed in. This is the domain we check most carefully. We test whether user A can read or change user B's data by editing a number in a request. For apps on Supabase, that means checking row-level security, the rules that decide which rows of each table a user may touch, on every table.

Security. Are secret keys kept out of the code that runs in the browser and out of the repository? Are the libraries the app depends on pinned and scanned? Is there a limit on how often someone can try to sign in, or call anything that costs you money?

Is your data safe, and does the app keep working when something fails?

Data. Are changes to the database made through versioned migrations, which are scripts that record every change so it can be repeated or reversed? Are backups automatic, and has anyone restored one recently? Is input checked on the server, not only in the form?

Reliability. What happens when a payment or email provider is slow or down? Can a payment be retried without charging someone twice? Are two people booking the last slot at once handled properly?

Testing. Is there an automated test that would fail if checkout or sign-up broke? Do tests run on every change? Tests matter most where money and data move, so that is where we look first.

Do the AI features behave, and can you see what the app is doing and spending?

AI features. Is there an evaluation set, a fixed list of example questions with the answers you expect, and a pass mark the feature must meet? What does the feature do when the model is wrong or unavailable? Is any action that cannot be undone approved by a person?

Observability means being able to see what the app is doing. Are errors captured with enough context to fix, and does someone get told? Are AI calls recorded with how long they took and what they cost? Could you explain what happened at a given minute yesterday in five minutes?

Cost. Do you know your monthly hosting and model spend per customer? Are there caps or alerts? Would a runaway loop cost you $50 or $50,000?

What do you get at the end of the five days?

Three things. A scored report covering all twelve domains, written so a founder can read it and an engineer can act on it. A prioritised risk register, which is a ranked list of every finding with what it could cost you and how hard it is to fix. And a fixed-price remediation proposal, so you know exactly what closing those findings would cost before you commit to anything.

You also get a call to walk through the report. The findings are yours to act on with us, with another team or on your own.

Should you start with the audit or the two-day triage?

The two-day triage costs $349. A senior engineer reads your repository and hosting setup and returns the five risks most likely to hurt you first, an indicative range for fixing them, and a recommendation: fix, harden fully, or in rare cases rebuild.

Choose the triage if you want a fast, honest read before spending more. Choose the audit if real users, payments or sensitive data are already live, or if you need a fixed quote rather than a range. Half of either fee is credited against the sprint that follows, if you proceed within 30 days.

What usually happens after the audit?

If you go ahead, the proposal becomes a hardening sprint with a defined scope. A stabilisation sprint, from $2,500 over one to two weeks, closes the findings that block launch. A production hardening sprint, from $6,000 over three to five weeks, covers the full set: permissions, secrets and environment separation, migrations and backups, failure handling, tests around money and data, a one-step rollback, error tracking and cost monitoring. Work is delivered to production, not left on a staging branch.

Can you check your own app before paying for anything?

Yes, and we would rather you did. Run the public checklist yourself, or take the eight-question self-check. If your app was built with Lovable, our page on fixing a Lovable app describes the problems we see most often with that tool and what we do about them. If nothing on the list worries you and no real users or money are involved yet, you probably do not need an audit today.