Direct answer: “Works in a demo” and “ready for production” are different claims. Before real users and real data arrive, test who can access what, how data is protected, what happens when the app fails, whether it can be recovered and whether another developer can safely maintain it.
A prototype can be useful without being production-ready
AI-assisted development is a legitimate way to explore an idea, test a workflow and learn what people need. A working prototype can be valuable evidence. The problem begins when its visible behaviour is treated as proof of the things a demo does not show: access control, data isolation, failure handling, recovery and maintainability.
Production readiness is not a judgement about how the first version was made. It is a judgement about what happens when real people depend on it.
Questions a non-developer can start asking
- 01Who can see whose data? Create different account types and try to reach records through links, search and changed web addresses. A hidden button is not access control.
- 02What happens when a dependency fails? Turn off a connected service or use invalid information. The app should fail safely, explain what happened and avoid duplicate work.
- 03Can anyone explain how it works? Another developer should be able to identify the main components, data model, deployment path and security boundaries without reverse-engineering every prompt.
- 04Is there a backup that has actually been restored? A backup setting is not enough. Recovery needs to be tested so the team knows what can be restored and how long the process takes.
- 05What happens under real use? Test concurrent actions, slow connections, large records and repeated submissions. A happy-path demo rarely exercises these conditions.
- 06Where do errors go? There should be logs and alerts that help someone diagnose a failure without exposing private data to the wrong people.
When to harden and when to rebuild
A professional review should recommend rescue or rebuild before assuming either. The purpose is to preserve useful work where it is safe to do so.
Harden when the foundation is understandable
Hardening is reasonable when the architecture is coherent, dependencies are supportable, the data model fits the product and the code can be tested. Work can then focus on authentication, permissions, validation, error handling, monitoring, deployment and documentation.
Rebuild when uncertainty is structural
A rebuild may be safer when nobody can explain the data boundaries, core behaviour is duplicated across generated files, secrets are exposed, the application cannot be tested, or each change breaks unrelated features. Rebuilding is not a punishment for using AI. It is a commercial decision about whether the current foundation can carry real obligations.
What a production-readiness review covers
- 01Access and identity: authentication, session handling, permissions and account recovery.
- 02Data protection: storage, transmission, validation, secrets and separation between customers or roles.
- 03Reliability: failure modes, retries, duplicate prevention, monitoring and support paths.
- 04Recovery: backups, restore tests, deployment rollback and ownership during an incident.
- 05Maintainability: code structure, tests, dependencies, documentation and a repeatable release process.
- 06Operational fit: whether the app actually supports the real workflow, exceptions and responsibilities.
Example: a portal that works only on the happy path
A founder has an AI-assisted customer portal that creates accounts and displays submitted records. The demo looks convincing. A review finds that changing the record identifier in the web address exposes another account’s data, failed payments create duplicate records and there is no tested restore process.
The product idea may still be sound. The correct next step is not a public launch and not automatically a total rebuild. First isolate the access flaw, protect the data, map the failure paths and assess whether the underlying structure can be tested and maintained. That evidence determines whether hardening or rebuilding is responsible.