Taking a vibe-coded prototype to production
AI coding tools let anyone who knows a problem build a working app in days. What it takes to turn that prototype into software a team can rely on, area by area, and why the answer is rarely a rewrite.
Key takeaways
- A prototype proves the idea is worth having. Production readiness is a different question, which is whether other people can safely rely on it.
- AI coding tools build the path you asked for. What usually needs attention is everything you did not ask about, such as access control, secrets, backups and tests.
- A readiness review covers nine areas, from sign in to deployment, and published references such as the OWASP guides give each one a yardstick.
- The usual answer is not a rewrite. Keep what real use has validated, strengthen what is sound and rebuild only what cannot carry the load.
- A few habits while prototyping, a real database, settings kept out of the code and a handful of tests, make the later step far cheaper.
Someone who knows a problem well can now sit down with an AI coding tool and have a working app by the end of the week. The practice has a name, vibe coding, and it has changed who gets to build software. A planner, an engineer or a supervisor can turn an idea into something people can click on without waiting for a project.
That is real progress, and the prototype is worth more than it looks. The hardest part of any software job is finding out what it should do, and a prototype that people already use has answered that. What it has not answered is whether it can be trusted with real data, real users and nobody watching it. This article sets out how to close that gap.
What a prototype proves, and what it does not
A prototype and a production system answer different questions. Treating one as the other is where the trouble starts.
| A prototype | A production system | |
|---|---|---|
| Question it answers | Is this worth having? | Can people rely on it? |
| Who uses it | The person who built it, and a few colleagues | A team, a site or a customer |
| When it breaks | The builder notices and fixes it | Someone has to be told, and work stops until it is fixed |
| The data | Samples, or a copy | The real thing, including what must stay private |
| Changes | Made whenever an idea arrives | Made without breaking what already works |
| If the builder leaves | It stops | It carries on |
A prototype is finished when it has taught you what to build. A production system is finished when you can stop thinking about it.
Why AI-built apps need a second look
The reason is not that the code is poor. AI coding tools often write tidy, working code. The reason is that they build what they are asked for, and a prototype is only ever asked to work on the path its builder tried.
Everything outside that path tends to be missing or assumed. The gaps below are common in prototypes of every kind, hand written ones included. AI tools simply make it possible to reach them faster.
- A password or key written straight into the code, where anyone with a copy can read it.
- Sign in that hides screens but does not stop a direct request for the data behind them.
- Data kept in the browser, a single file or a free hosted database with no backup.
- No automated tests, so nobody knows what a change has broken until a user finds out.
- Errors that are quietly swallowed, leaving a blank screen and no record of what happened.
- Libraries added because the tool suggested them, with nobody checking their security record or licence.
- A deployment that exists only on the builder's laptop.
A readiness review in nine areas
A review works through the app area by area and asks the same question of each. Is this good enough for the people and data that will depend on it? The published guides in the last column give a yardstick, so the answer is more than one reviewer's opinion. They are reference points to draw on in proportion to the risk, not a checklist every small app has to pass in full.
| Area | What to check | A reference point |
|---|---|---|
| Sign in and access | Every request is checked on the server for who is asking and what they may see or change | OWASP Application Security Verification Standard |
| Secrets and settings | Keys and passwords live outside the code, with separate settings for test and live | The Twelve-Factor App |
| Data | A proper database with a clear structure, checked input and a backup that has been restored at least once | ASD Essential Eight, for backups |
| Code and dependencies | Common weaknesses are tested for, and third-party libraries are current, supported and correctly licensed | OWASP Top 10 and the NIST Secure Software Development Framework |
| Tests | Automated tests cover the paths people rely on and run before every release | NIST Secure Software Development Framework |
| Failure and recovery | Errors are shown to the user honestly, recorded and raised to someone who can act | The Twelve-Factor App, for logs |
| Deployment | A new version is built and released the same way every time and can be rolled back | The Twelve-Factor App |
| Privacy and records | Personal information is identified, protected and held where it is allowed to be, and changes can be traced to a person | Australian Privacy Principles |
| AI features | If the app calls an AI model, it handles misleading input, checks what comes back and caps what it can spend | OWASP Top 10 for Large Language Model Applications |
Going through all nine means the gaps are found by the review and not by the first serious incident.
Keep, fix or rebuild
The fear behind most reviews is that the answer will be to throw the prototype away. It rarely is. The parts users touch, the screens, the workflow and the rules about what happens when, have been shaped by real use and are usually the most valuable thing in the project.
What sits underneath is a different matter, and the decision turns on three questions. Is the data structure sound enough to grow? Is the code organised enough that tests can be added? And how much is at stake if it fails?
| What the review finds | Usual answer |
|---|---|
| Screens and workflow people already use happily | Keep. This is what the prototype was for |
| Sound structure with gaps in access, tests or error handling | Fix. Add what is missing around the existing code |
| Data in files or the browser, or a structure that cannot hold what is coming | Rebuild the data layer and keep the screens |
| Secrets in the code or its history | Fix at once, and replace every exposed key |
| Logic tangled so tightly that no part can be tested alone | Rebuild that part, using the prototype as the specification |
A working prototype is the best specification a rebuild can have. Nothing in it was guessed.
What production ready means on an industrial site
An app for an operation carries a few demands that an office tool does not. It may have to work where the network drops, exchange data with a maintenance system or a historian, survive a shift change without anyone entering everything again and leave a record that stands up when a decision is questioned later.
Those needs shape the work as much as the nine areas do. Reading from plant systems should be one way by design, and an app that people depend on around the clock needs a plan for what it does when something upstream fails. We cover that ground in building software that runs a 24/7 operation.
Habits that make the next prototype easier to promote
None of this is a reason to prototype more slowly. A few habits cost almost nothing while building and remove most of the expensive findings later.
- Ask the tool to keep keys and passwords in a settings file that never goes into the code repository.
- Start on a real database, even a small one, so the structure is deliberate from the first day.
- Keep the code in version control and save changes often, so every change can be seen and undone.
- Ask for a few tests on the calculations and rules that matter most, and run them before sharing a new version.
- Write down the decisions the app encodes, such as who may approve what, in a short note beside the code.
- Use made-up or anonymised data until access control is in place.
Where a review fits
If you have a prototype that people have started to rely on, a prototype review is the short way to find out where it stands. It covers the nine areas above and ends with a clear call on what to keep, fix and rebuild. How we take that work on, and the other ways we build software with AI, is set out on our Software and AI page.
From prototype to production
Review
Work through the nine areas and rank what was found.
Decide
Keep, fix or rebuild, part by part.
Harden
Access, data, tests, error handling and monitoring.
Launch
A repeatable release, to a small group first.
Run
Supported, backed up and safe to change.
Review
Work through the nine areas and rank what was found.
Decide
Keep, fix or rebuild, part by part.
Harden
Access, data, tests, error handling and monitoring.
Launch
A repeatable release, to a small group first.
Run
Supported, backed up and safe to change.
Common questions
Is AI-generated code safe to put into production?
It can be, once it has been reviewed and tested like any other code. Where the code came from matters less than whether someone accountable has read it, tests cover what people depend on, and the areas a prototype usually skips, such as access control and backups, have been dealt with.
What is vibe coding?
Building software by describing what you want to an AI coding tool and steering by whether the result works, without necessarily reading the code it writes. It is fast and well suited to prototypes. The term dates from early 2025.
Do we have to rebuild the app from scratch?
Usually not. The screens and workflow that people already use are normally kept. What gets rebuilt, where anything does, is the part underneath that cannot carry real data or real users, most often how data is stored and how access is controlled.
How long does it take to make a prototype production ready?
It depends on what the review finds and on what is at stake. A small internal tool with a sound structure may need only a short piece of work around access, backups and tests. An app that holds sensitive data or connects to plant systems needs more. The review is what turns that into a scope.
Can we keep building with AI tools afterwards?
Yes. A production ready app is a better base for AI tools than a prototype, because tests catch a bad change and the structure shows the tool where things belong. The same review habits apply to every change, whoever or whatever wrote it.
Key terms
Plain-language definitions from our glossary for the concepts this article leans on.
Standards and further reading
- Application Security Verification Standard (OWASP)
- OWASP Top 10, the most common web application security risks (OWASP)
- Top 10 for Large Language Model Applications (OWASP)
- The Twelve-Factor App, a method for building software that runs as a service (12factor.net)
- Secure Software Development Framework (NIST)
- Essential Eight (Australian Signals Directorate)
- Australian Privacy Principles (Office of the Australian Information Commissioner)
Related case studies and tools
- Bridging OT and IT with custom software (case study)
- Shutdown coordination platform (case study)
Related reading
Working through something like this?
See how we approach these initiatives, or tell us what you are dealing with.