What an AI MVP audit checks before you scale

An AI MVP audit checks whether an app built with Lovable, Bolt, Cursor or a similar tool will hold up once real users arrive: the flows and states around the happy path, UI consistency, accessibility, the security and data basics, performance, analytics and content. A design-led audit like ours finds the problems users and investors will notice and flags the security risks it can see, but it is no substitute for a penetration test, and anyone selling it as one is overselling.

This extends the six-line checklist in Lovable, Bolt and Cursor to production, which sets out the order to clean up in. Below is the full list we work through at the audit stage, grouped by area, so you can run most of it yourself before paying anyone.

What a design-led audit covers, and what it does not

Be clear on this before you buy an audit from us or anyone else. A design-led audit looks at the product the way a user, an investor and a future developer will meet it. It will catch an admin page anyone can open by changing the URL, a secret key visible in the browser, or a form that accepts anything at all. It will not find a subtle injection flaw, test your infrastructure or certify anything.

Lovable says much the same about its own tools. Its documentation describes built-in Quick and Deep security scans that cover database access rules, dependencies and application code, and states that they do not replace a thorough security review, recommending an additional professional review for apps that handle sensitive data. Run the scans. Then treat them as the floor.

1. UX flows and states

This is where AI-built apps lose most users, so it comes first. The builder made the screens you asked for, populated with tidy sample data, and very little of what happens around them.

• Walk the journeys real users take: sign up, first use, the core task, coming back a week later, and leaving.
• Every list, table and dashboard has a first-use empty state that explains what goes there and offers one action. Our guide to empty states covers the four kinds.
• Every screen that loads data has a loading state, and the layout does not jump when the data lands.
• Every action that can fail has an error message saying what happened and what to do next, in words a user would use.
• No dead ends. Every screen has a way back and every modal has a way out.
• Destructive actions confirm with the consequence written out, and can be undone where possible.
• Permissions are designed: what someone without access sees, and what an invited teammate sees on their first day.
• Forms keep what the user typed when validation fails.
• Sessions expire without throwing away unsaved work.

2. UI consistency

AI builders make a fresh set of design decisions with every prompt, so the audit counts how many decisions were made.

• Buttons: how many distinct primary button styles exist. The right answer is one.
• Colour: how many greys, blues and reds are in use, and whether they come from a defined set of tokens or were typed in by hand.
• Type: a clear scale of sizes and weights, each used for the same job everywhere.
• Spacing: values from one scale, so the gaps do not differ by a few pixels from screen to screen.
• Components: one card, one modal, one table and one form field, each reused everywhere it appears.
• Icons from a single set, at consistent sizes and stroke weights.
• Responsive behaviour checked on a real phone. A narrowed desktop browser misses most of what goes wrong.

3. Accessibility

AI-built apps fail here predictably, because the defaults look fine to the person prompting and nobody tries the app with a keyboard. We check against the basics of WCAG 2.2 at level AA.

• Text contrast of at least 4.5:1 for normal text and 3:1 for large text, which is what WCAG 2.2 requires at AA. Pale grey helper text is the usual offender.
• Every interactive element works with a keyboard alone, in a sensible order, with a visible focus state.
• Form fields have real labels, not just placeholder text that disappears the moment someone types.
• Images that carry meaning have alt text, and decorative ones are hidden from screen readers.
• Click and tap targets are at least 24 by 24 CSS pixels, or spaced so they cannot be mis-hit, as WCAG 2.2's target size criterion sets out.
• Errors are described in text, not signalled only by a red border.
• Nothing relies on colour alone to carry meaning, including charts and status badges.

4. Security and data basics a designer would flag

None of these needs a security specialist to spot. All of them need an engineer, and sometimes a specialist, to fix properly.

• Pages that should require a login and do not, or that show another user's data when you change an ID in the URL.
• API keys or secrets visible in the browser's developer tools.
• Database rules that let any logged-in user read every row. In Lovable and Supabase projects that means checking row-level security is switched on and restricts what it should.
• Forms with no validation, no length limits and nothing stopping someone submitting them a thousand times.
• Password reset, email change and account deletion flows that exist and work end to end.
• Personal data collected without a reason, or kept with no way for a user to delete it.
• Payments taken through a payment provider's own checkout or components, never a card form the AI built from scratch.

5. Performance

• Core Web Vitals on the pages that matter. Google's web.dev guidance puts a good Largest Contentful Paint at 2.5 seconds or less, Interaction to Next Paint at 200 milliseconds or less, and Cumulative Layout Shift at 0.1 or less, measured at the 75th percentile of real visits.
• Images sized and compressed for the screens they appear on.
• Long lists and tables that page or load progressively, so no screen fetches every row in the database.
• No request chains where one screen makes twenty calls in a row before anything appears.
• Tested on a mid-range phone on a mobile connection, which is closer to your users than your laptop on office wifi.

6. Analytics

• An activation event is defined: the moment a new user first gets value. If nobody can name it, start with choosing an activation metric at seed.
• Sign-up, activation and the core task are tracked as events, with consistent names.
• Funnels can be built from those events without asking a developer.
• Errors are logged somewhere a person actually looks.
• Consent is handled for the markets you sell in before tracking fires.
• Session recordings, if you use them, mask what people type into forms.

7. Content

• No lorem ipsum, "Acme Inc" or sample names left in production. Search the codebase for them. It takes a minute.
• One name for each thing. If it is a project on one screen and a workspace on the next, users assume they are different things.
• Buttons say what they do. "Create invoice" beats "Submit".
• Error messages written for people, not stack traces or "Something went wrong".
• Legal pages exist and match what the product actually does with data.
• The emails the product sends, welcome, password reset and invite, are written and branded. Unbranded platform defaults read like spam.

What you should get at the end

A long list of findings is the least useful thing an audit can hand you. What you want is a ranked list: what is risky now, what is losing users, and what can wait, each with a plain-language reason and a rough size. That is what the audit phase of our AI MVP Cleanup produces, and the fixed price for the rest of the work comes from it.

It is how we start on any product that has drifted. When OCTA came to us after working with another agency, with a pre-seed raise approaching, we began by auditing the core journeys and features and building a roadmap from what we found, before redesigning anything. OCTA's product came from an agency rather than an AI builder, but the logic is identical: you cannot prioritise fixes you have not listed. OCTA closed a $2.25M pre-seed shortly after the redesign.

If you are still deciding whether you need an audit at all, a useful rule of thumb: when the same fix takes three prompts, or fixing one screen breaks another, the structure has become the problem and an audit will pay for itself. If you have not yet shown the product to customers, do that first.