The guide · AI-built apps

What breaks when
AI builds your app.

Lovable, Replit, Cursor, Bolt, v0 — the fastest way anyone has ever shipped an MVP. But AI-generated code fails in six predictable places, and every one of them is invisible in the demo. Here is what they are, why they happen, and how to check your own app — including a free self-check, no email required.

HighStack fit

Did AI pick the right stack for your product?

AI chooses technology from how you phrased the prompt, not from what your product needs. Ask for “an app like Airbnb” and you get whatever framework the model saw most often next to those words — which may be fine, or may be a front-end framework carrying a back end it was never meant to hold.

The result is not always wrong. That is what makes it dangerous: a wrong-enough stack works perfectly at demo scale and only shows its ceiling when real load, real data, or a real feature roadmap arrives. The question the audit answers first is rebuild vs. repair — and most of the time, the honest answer is repair.

Self-check: can you name why your app uses the framework it uses? If the only answer is “that’s what the AI chose,” nobody has made that decision yet.

CriticalSecurity

Is the auth secure, or just working?

This is the category that earns the CRITICAL tag. AI-generated auth passes the demo — signup works, login works, the dashboard loads. But security is not whether auth works; it is what happens when someone attacks it. Generated code routinely stores tokens where scripts can read them, skips rate limiting on login, checks roles only in the interface, and accepts payment webhooks without verifying who sent them.

The mechanism is simple: you prompted for a login flow, and the model gave you one that logs people in. You did not prompt for “and survives a hostile user,” because founders never do — that requirement lives in an engineer’s head, not in a prompt.

Self-check: open a private browser window, stay logged out, and paste in the URL of a page that should require an account. Then try changing an ID in any URL. If either works, stop reading and get this fixed.

HighArchitecture

Why do AI-built codebases resist change?

AI assistants generate; they do not refactor. Ask for a change and the model writes new code next to the old code rather than reshaping what exists. After a few months of prompting, the same logic lives in five places with slight differences, and no part of the codebase has one owner.

You feel this as slowing velocity: every new feature takes longer than the last, and every change breaks something unrelated. That is not a tooling problem — it is duplicated logic drifting apart. It is also the most fixable category on this list, and fixing it is what makes every later feature cheaper.

Self-check: ask your AI tool to change one small feature. If the diff touches files that have nothing to do with the feature, the structure is already fighting you.

HighPerformance

Why is your app slow in ways you can’t see yet?

Demo data hides everything. A query with no index is instant on 200 rows and a ten-second timeout on two million. A page that loads one record per item works with ten test users and collapses with five hundred real ones — the classic N+1 problem, and AI generates it constantly because the naive version is the most common version in its training data.

Performance debt is invisible until the exact moment you can least afford it: the launch spike, the press mention, the investor demo. Finding it early is cheap; finding it live is not.

Self-check: how many rows are in your biggest table right now? If the answer is under ten thousand, your app has never actually been tested.

HighObservability

How would you know if it broke right now?

Most AI-built apps ship with no error tracking, no structured logs, and no alerting — because nobody prompts for the instruments. The app either works or it doesn’t, and the founder finds out which from a customer email.

This is the cheapest category to fix and the one with the fastest payoff: an afternoon of wiring error tracking and log retention turns “a customer said something is broken” into “we saw the error before the customer did.”

Self-check: when your app last threw an error in production, how did you find out? If the answer involves a human telling you, you have no observability.

SolidReadiness

What’s the path from demo to product?

This one is a SOLID, not a failure — because it is the output, not the problem. Every category above ends in the same question: what do I fix, in what order, at what cost? That ordered list is what a production-readiness roadmap is.

Our fixed-price code audit ends with exactly that: every finding rated CRITICAL, HIGH, or SOLID, what each costs you if unfixed, and a sequenced plan — whether we do the fixing or you hand the list to any engineer you trust.

Self-check: if an investor asked “what stands between this demo and a product,” could you answer in writing? The audit’s job is to make the answer yes.

Free self-check · 2 minutes

Is your app
production-ready?

Ten questions, mapped to the same categories the paid audit checks. No email, no signup — the verdict renders right here. Answer honestly; the only person you can mislead is you.

  1. Security

    If you open your app in a private window while logged out, can you still reach pages or data that should require an account?

  2. Security

    Can one customer see another customer’s data by editing an ID in the URL?

  3. Payments

    Do you know what happens when a payment webhook is delivered twice — or not at all?

  4. Security

    Are any API keys or secrets visible in your browser’s view-source or network tab?

  5. Security

    Has anyone ever tried logging in wrong 50 times in a row — and did anything stop them?

  6. Observability

    When something breaks in production, do you find out from a log or alert — or from a customer?

  7. Data

    Do you have a backup of your database that you have actually restored at least once?

  8. Performance

    Does your app stay fast with 100× your current data volume (have you tested it)?

  9. Architecture

    If you asked your AI tool to change one feature today, are you confident nothing unrelated would break?

  10. Architecture

    Could an engineer you hired tomorrow understand the codebase without you explaining it?

0 of 10 answered — your verdict appears here.

The audit · What you receive

What a $995 report
actually contains.

Not a per-task patch and not a pen-test — a full written audit of your codebase, structured so you can hand it to an investor, a co-founder, or any engineer. Every report follows the same spine:

1

Executive summary

One page, plain English: the overall verdict, the single most important finding and its business consequence, and finding counts by severity.

2

Scorecard

Six areas, traffic-light rated: auth & authorization · payments & money paths · data handling & privacy · errors & observability · code structure · deploy, secrets & infrastructure.

3

Findings, rated by severity

Every finding: where it is (exact files), what is happening, why it matters in business terms, how it likely got there, and what fixing it takes.

4

What’s solid

The things done well — always included. It proves the code was read, not pattern-matched, and it makes the criticism credible.

5

Production-readiness roadmap

The fix list in severity order, grouped this week / this month / this quarter — take it to us or to any engineer you trust.

Common questions

Why does AI-generated code break in production?

AI coding tools optimize for the prompt you wrote — the happy path. Production is everything off the happy path: a hostile user probing your auth, a payment webhook delivered twice, a database at 100 times the demo volume. Those need judgment about what could go wrong, and judgment is exactly what code generation does not have. The failures cluster in six predictable places: stack fit, security, architecture, performance, observability, and the path from demo to product.

Is my Cursor or Lovable app secure?

You cannot know without reading the code, but the common pattern is: the auth works and is not safe. AI-generated login flows routinely pass the demo while storing tokens insecurely, skipping rate limiting, trusting client-side role checks, or accepting unverified webhooks. A five-minute self-check catches some of it — open a private window and try to reach data while logged out, or edit an ID in a URL to reach another account. A fixed-price code audit ($995, five business days) reads every auth and payment path and rates each finding by severity.

What is vibe coding, and does it need rescuing?

Vibe coding is building software by prompting AI tools — Lovable, Replit, Cursor, Bolt, v0 — and accepting what they generate. It is the fastest way anyone has ever validated a product idea, and nothing about it is wrong. The rescue part comes later: vibe-coded apps ship with the production 20% missing — hardened auth, safe payment handling, an architecture that survives change. That gap is fixable without a rebuild in most cases.

Should I rebuild my AI-built app from scratch?

Usually not. Most AI-built codebases are salvageable: the product logic is real, the gaps are concentrated in security, structure, and performance. A rebuild throws away validated work and costs months. The honest way to decide is an audit that ends with a rebuild-or-repair verdict per area — which is exactly what our written report includes.

More on how engagements work: how we work, or read the guides.