Vibe coding to production: what the prototype is missing
For founders · Updated
Filip Papranecfounder of Digitaliko
Taking vibe coding to production means adding what the AI tool won't do on its own. Secure login and permissions, passwords outside the code, backups, repeatable deployment, tests and monitoring. The prototype is not wasted. It is the best brief you can give a vendor.
Vibe coding gets you a prototype. We build software that runs a business. Below we describe what a prototype is missing, how to check it and when starting over pays off. What vibe coding is and why software got cheap, we explain in Vibe coding: what it is and why software got cheap.
What is vibe coding, and where does it stop?
Vibe coding means describing to an AI tool what you want and accepting the code it produces without reading it. Over a weekend you get an app you can click through. A few years ago that took a developer and months.
Vibe coding lowered the barrier to entry, but it did not raise the ceiling. Almost anyone can create a prototype today. But the first real rush of users, the first attack or the first lost database shows what is missing. The tools are the same. Engineering discipline around them makes the difference.
What is a prototype missing for live operation?
These are the points we check when we take a prototype into live operation. If something on it is missing, that is not a reason for a rewrite. It is a work list.
| Area | In the prototype | In live operation |
|---|---|---|
| Login and permissions | Works on the main screen | The same check on every entry point, including the API |
| Passwords and keys | Often right in the code | Outside the repository, rotated if they were ever there |
| Data | One database without backups | Backups you have restored at least once |
| Deployment | By hand, from one computer | One command, repeatable, with a way back |
| Tests and CI | None, or green without substance | Tests that fail on a bug, and CI that blocks |
| Monitoring | A customer reports the outage | An alert arrives before the customer's complaint |
| Accounts | On the personal account of whoever clicked it together | On the company, with access for several people |
The first row is the most treacherous. Vibe-coded code is rarely bad. It is inconsistent. The AI gets access control right once and forgets it in the file next door. We saw it in an audit of a vibe-coded product: one file had a correct login check, and the endpoints next to it served files without any login. The fix is then quick, but finding the gap means looking at everything.
The full list of 25 checks, with a way to verify each one without a developer, is in the PDF. Download the 25 checks before launch (PDF).
Is your prototype ready? A quick test
Tick what is true for your app. Every unticked item is one task before launch.
Why is monitoring on the list when the app is running?
Because whatever runs unwatched will one day quietly stop. It happened to us too. On a project for a client with an online marketplace, a crawler stopped running in December 2025. We noticed it late, only from a chart. Meanwhile traffic fell from 250,000 to 66,000 pageviews a month.
- pageviews a month after a crawler quietly stopped running in December 2025
- 250K → 66K
What was missing was an alert that would have reported the outage the same day. That is why monitoring is mandatory, not a bonus, every time something moves into live operation.
Continue with the prototype, or start over?
Usually continue. When we audited one founder's prototype, we did not recommend a rewrite. We recommended hardening it: a few security fixes, working deployment and then normal work. Starting over only pays off when the fixes would take longer than a new version.
That can only be said honestly after looking into the code. The three possible verdicts, and what to ask for if someone else wrote the app, are covered in How to take over an app from another vendor.
Even when the code is rewritten, the prototype stays. It shows how the product should work better than any specification. You know how your company works. Our job is to get that into software that lasts for years.
Do you have to stop vibe coding?
No. If you enjoy trying out new screens yourself, keep going. We set up the repository so your experiments fit into the rest of the system. They go through the same tests and the same code review as everything else.
I don't have anything against vibe coding. Non-tech people finally get to build things. But I haven't seen a single vibe-coded project survive production without someone eventually calling in engineers.
You keep figuring out how the product should work. We make sure it holds up in live operation. That is what our MVP development for founders is about. If an agency was building your app and it got stuck, also see The agency didn't deliver the app. What now?.
When we don't recommend it
- Only you or a few colleagues use the prototype internally. It does not need to go into production. Just back up the data.
- You are testing an idea and have no users yet. Keep vibe coding yourself. Look for a vendor once someone wants the product.
- You want a finished platform with everything in month one. We will not promise that. We start with what the first users need.
- You want someone to build it for equity. We do not do that. Look for a technical co-founder.
What should you prepare before the first conversation?
You don't need a specification. Three things are enough:
01
Access to the code
An invite to the repository, or an export of the project from the AI tool.
02
Who uses it
Who uses the app today and for what.
03
What hurts
What has already broken, or what you are worried about.
Want to get your prototype to customers?
Send us those three things. We get back to you within two business days, and together we pick what to fix first.
If you'd rather talk first, book a 15-minute meeting with Filip.
What does your prototype still need before your first customers can use it?
In short
- A vibe-coded prototype is a good brief. What it lacks for production is what the AI tool won't do on its own.
- Before launch, check login on every entry point, keys outside the code, restore from backup, deployment with CI and monitoring.
- Missing items are not a reason to rewrite. They are tasks. Starting over pays off only when fixes would take longer than a new version.
- Monitoring is not a bonus. Whatever runs unwatched will one day quietly stop.
Frequently asked questions
What is vibe coding?
A way of creating an app by describing to an AI tool what you want and accepting the code it produces without reading it. For a prototype it is fast and cheap. For live operation it lacks oversight.
Can a vibe-coded app go to production?
Yes, but not as it is. First you need to check login and permissions, get passwords out of the code, and set up backups, repeatable deployment, tests and monitoring.
Does a vibe-coded prototype need a rewrite from scratch?
Usually not. More often it is enough to harden security and operations and then carry on. Whether a rewrite is needed can only be said honestly after looking into the code.
Is a vibe-coded app secure?
You cannot tell without checking. The most common problem is not bad code but inconsistent code: one part has proper login, the part next to it hands data to anyone. Every entry point needs checking.
Can I keep editing the app myself after a takeover?
Yes. The repository can be set up so your experiments fit into the rest of the system and go through the same checks as the rest of the code.
Ask AI about this article
The AI also draws on our other articles and experience from real projects.
ChatGPTClaudePerplexity
