If you have built a working app with an AI coding tool, you have already done useful work.
You have turned an idea into something people can see and use. You may have tested a workflow, learned which parts matter and discovered that a customer wants it. That is a much better starting point than a specification full of guesses.
Production does not make that work disappear. It changes what the app must prove.
A prototype needs to show that the idea is useful. A production service needs to keep customer information separate, survive failure, accept controlled changes and give somebody responsibility when things go wrong. Much of the app may be worth keeping. The work now is to find the parts that customers cannot safely depend on yet.
Your prototype has already removed uncertainty
Traditional software projects can spend weeks describing a product before anyone has used it. A working prototype gives you evidence much earlier.
You can watch somebody complete the core task. You can see which screens confuse them, which data the workflow actually needs and whether the outcome is valuable enough to pay for. You may also have working integrations, a useful data model and business rules that are already clearer because the app exists.
An engineering review should respect that progress. Starting again by default would throw away product learning along with technical shortcuts.
The better approach is selective. Keep the journeys that work. Test the assumptions hidden underneath them. Replace or reinforce a component when the evidence says it cannot carry the risk of live use.
This matters commercially. The prototype can shorten the route to a useful first release because the team is no longer starting from a blank page. It shows where to focus time and where another round of design would add little.
A customer changes the promise
The first paying customer introduces a different kind of pressure. They are no longer helping you explore an idea. They are trusting the service with their work, their information or their own customers.
That trust often concentrates in three areas.
The first is control. Does the business own the source repository, deployment platform, database, domain, billing and recovery accounts? Can another competent engineer understand the running version and change it without the original chat history? The NCSC's secure-development guidance treats version control, review and automated tests as ordinary controls for safe change. Generated code benefits from the same discipline.
The second is the customer boundary. A login screen is only the start. The service must enforce what each user can read, change, export and administer. In an app used by several customer organisations, a valid user must never reach another customer's record by changing an identifier, following a file URL or using a shared search. AWS separates tenant isolation from basic authentication for this reason.
The third is recovery. What happens when a deployment fails, an integration stops responding or a credential expires? Useful logs, tested backups and a named support route matter because the customer will experience the failure as a broken service, not an interesting technical problem.
These are not reasons to dismiss the prototype. They are the questions that identify where professional engineering adds value.
Keep the useful parts and test the dangerous ones
An exhaustive production checklist can make a promising app feel further away from launch than it is. Risk gives the work a better order.
Start with the customer journey that creates the most value. Follow the information it reads and changes. Look at the permissions, integrations and failure paths around that journey. Then ask what the consequence would be if the app showed the wrong information, exposed it to the wrong customer or lost the change entirely.
That determines the depth of review.
A private calculator using public data needs a different level of assurance from a customer portal holding commercial documents. An app that drafts a recommendation needs different controls from one that automatically sends it or commits a financial action.
OWASP's Application Security Verification Standard can provide a shared basis for security requirements. The ICO's guidance makes privacy part of design and operation, including what personal information the app uses, why it is needed, who receives it and how long it remains. These frameworks help a team test the right things without treating every product as if it carried the same risk.
The review should end with a small number of decisions: what can stay, what needs strengthening before launch and what must be restricted to a smaller first group.
Move into production without pretending it is finished
The first production release does not need every feature or every customer.
Limit the initial boundary. Choose named customers, known roles and one important journey. Keep higher-risk actions behind human approval. Watch failed journeys and broken integrations. Test recovery before the first real incident. Give customers a clear support route and give the team a safe fallback.
The GOV.UK live-service guidance asks whether a service can be supported, monitored, secured, tested and improved over time. Those are useful questions for any business moving a prototype into live use.
Some answers may already be strong. Others may be hard to reach because ownership, customer separation or recovery was never part of the experiment. That does not mean the work was wasted. It tells you where the prototype ends and the production service begins.
If you have a useful vibe-coded app and the next questions are difficult, book a production-readiness conversation. Bring the app and the customer journey. We can keep the work that accelerates the product and identify the smallest set of changes needed for a credible first release.