The right time to audit an AI-built app cannot be reduced to a user count. A simple architecture may support several thousand people, while another project may become hard to maintain before its first paying customer.
The important signal is a change in the product's role. At first, the app tests an idea, a journey and a market. It later needs to be handed over, extended and operated against clearer commitments. That is when engineering needs to complement the speed provided by vibe coding.
These are the six situations that most often justify an assessment.
1. Another person needs to take over the code
The founder is no longer the only person working in the tool. A developer, agency or internal team needs to understand the project, run it locally and estimate a change.
File length alone does not determine quality. A very long file may still reveal several responsibilities mixed together. The decisive signal appears when the person taking over cannot isolate a feature, run tests or explain dependencies without reconstructing the whole application in their head.
2. Every change is becoming hard to predict
A small change needs several attempts. A fix reintroduces an earlier problem. The tool edits parts of the project that appeared unrelated to the request.
This does not automatically justify a rebuild. It suggests that code boundaries, tests or dependency management no longer provide enough protection. An audit can separate a few areas that need isolation from a structural issue.
3. A third party asks for assurance
A customer wants to know where data is stored. An investor asks who owns the code. A partner wants to understand backups or incident recovery. A technical team needs to estimate the next phase.
These questions require more than a general promise. They need a map of components, accounts, access and responsibilities. The Scan turns that map into answers a non-technical decision-maker can understand and a developer can verify.
4. The app starts to carry commitments
Payments, personal data, an important contract, an availability requirement or access for an organisation change the consequences of failure, even while the user count remains small.
Safeguards should match the context: access policies, backups, authentication, logs, alerts and recovery procedures. The launch checklist helps identify some of those needs.
5. The platform starts making decisions for you
A feature relies on a service you cannot replace. Costs become hard to forecast. The domain, data or keys live in a poorly identified account. A team cannot reproduce the deployment elsewhere.
Leaving the platform is not automatically the answer. Lovable, Bolt, v0, Replit and Base44 may remain strong choices. The audit separates an accepted dependency from an unknown constraint and documents an exit path when the project needs one.
6. You can no longer price the next phase
You know what needs to be added, but nobody can say whether it will take two days or six weeks. Every estimate carries a large contingency because the code, data and dependencies remain unclear.
This is often closest to the real economic problem. Technical debt does not only cost money when the app fails. It costs money whenever a decision slows down, a quote must price more uncertainty or a team refuses the handover because it lacks visibility.
What does not constitute a verdict
An app is not doomed because AI helped build it, because one file is long or because it is approaching a particular user count. None of those facts alone justifies a rebuild.
The decision should compare evidence: cost of correction, handover difficulty, confirmed risks, product trajectory and the cost of an alternative. In most cases, a targeted Production Upgrade preserves what already works. A Rebuild remains appropriate only when correcting structural limits costs more than replacing them.
Three stages, three levels of discipline
During exploration, the basics checklist protects code, accounts and data. Once a usable version exists, a few tests and minimum documentation already make handover easier. When several of the six signals appear, the Scan provides a decision base before more development is commissioned.
The choice is therefore not between vibe coding and traditional development. AI can remain part of the project. The objective is to recognise when its speed needs explicit engineering decisions around it.