Take an AI-generated prototype to production

The twelve axes we harden against

An AI-generated prototype is not badly built so much as built for a different objective. The generator optimised for something working within minutes, which is a genuinely different goal from something surviving real users, an auditor, and eighteen months of changes. The gaps are therefore predictable, and they cluster in the same places regardless of which tool produced the app, which is why a fixed rubric is more useful here than an open-ended review.

Each tool page below documents the gaps specific to that generator, because they differ in interesting ways — what is scaffolded for you, what is stubbed, what is quietly absent. The rubric underneath is the same in every case, and the first week of any engagement is spent ranking the findings by exposure rather than by effort, so that whatever would actually hurt you if a real user arrived tomorrow gets closed first.

What gets assessed

• —Authentication — session handling, token lifetimes, and the failure paths a happy-path implementation skips.
• —Authorisation and data boundaries — whether any authenticated user can read anything, and whether row-level policy exists at all.
• —Secrets — what is committed, what is embedded client-side, and what a rotation would actually involve today.
• —Schema and migrations — whether schema change has a history and a reverse, or is a manual edit against production.
• —Backups and restore — not whether backups exist, but whether a restore has ever been performed.
• —Input validation — server-side enforcement rather than a form that is polite about what it accepts.
• —Rate limiting and abuse — what stops one caller, or one agent loop, exhausting the service or the bill.
• —Error handling and logging — whether a failure in production is diagnosable without reproducing it locally.
• —Dependency provenance — whether every package existed and was trusted before a model suggested it.
• —Tests — enough coverage on the paths that matter that a change can be made without fear.
• —Deployment repeatability — whether the environment can be rebuilt from source, or exists only as configured state.
• —Observability — cost, latency and errors visible per feature, which for AI features means per route.

What to do before you call anyone

Two checks are worth running yourself first, because they change the size of the problem. Confirm whether your database enforces row-level access, by signing in as one test user and attempting to read another's data through the API rather than the interface. And search the repository and the built client bundle for anything resembling a key or a token. Those two findings account for most genuine emergencies in this category, and both are things you can establish in an hour.

If either fails, treat it as urgent rather than as scope for a project — close the exposure first, and plan the rest of the hardening afterwards. If both pass, you are in better shape than most prototypes we see, and the remaining work can be sequenced calmly against whatever your real launch date is.