The pitch for vibe coding is real. You describe what you want, an AI builds it, and in a few days you have something that looks like a product. For close to nothing. Compared to hiring a developer for three months, the upfront cost is almost zero.

That part is true. The part people find out later is what the rest of it costs.

This isn't an argument against using AI to build things. It's a true-cost-of-ownership piece. When you buy a car, the sticker price is one number. Registration, insurance, fuel, tyres, servicing, and the timing belt you forgot about are other numbers. Neither the dealer nor the AI builder tool is going to volunteer that information. You have to go looking for it.

What you actually get in the prototype

A vibe-coded prototype is real. It runs. You can click through it and demo it to investors and customers. That's not nothing, it's actually quite valuable as a signal that the idea works and people respond to it.

What the prototype typically doesn't have:

Authentication that's correct, not just functional. There's a difference between an app that requires login and an app where your data is actually isolated from every other user's data. AI-generated auth is usually the first kind. The route says "you must be logged in." The query behind it says "give me all records of this type." If someone knows how to read the URL structure, or knows what requests to make, they can often pull other people's data. The app works. The security doesn't.

Multi-tenancy that's actually enforced. If your product has multiple customers, each of those customers' data needs to be scoped to them at every layer, not just the interface. Vibe-coded apps frequently get this wrong at the database query level. The bug is invisible in normal use and catastrophic when exploited.

Error handling that means anything. When something fails in a prototype, the failure is usually silent or generic. No logging, no alerting, no record that it happened. In production, that means problems accumulate invisibly until something very obvious breaks or a customer complains.

A data model built to last. The data model is the structure of your database, the tables, the relationships, the way entities are represented. AI tools make decisions about this quickly, based on the information you gave in the prompt, without asking deeper questions about how your business actually works. When those decisions are wrong, and they often are in subtle ways, everything built on top of them is also wrong.

Secrets management. API keys, database credentials, third-party service tokens. In many vibe-coded projects these end up in the codebase or in environment variables that get committed to a repository. Once that happens, you don't know who has them. You don't know whether the repository was ever public. You can't be sure those credentials are still private.

Backups and recovery. The database exists somewhere. What happens if the hosting provider has an incident, or someone runs a bad migration, or data gets deleted by accident? If the answer is "I'm not sure," that's a real cost waiting to happen.

None of this is meant to be a frightening list. It's meant to be a complete list, because the prototype doesn't come with one.

The cost of fixing what's there versus starting clean

This is where vibe coding costs start to compound in ways people don't anticipate.

When a codebase has been built quickly by an AI without a consistent architecture, without tests, without clear documentation of what choices were made and why, working with it is expensive. Developers who pick it up spend time figuring out what it does before they can change it. Every new feature has to work around decisions that were made earlier and can't easily be undone.

The specific pattern that causes the most pain is a bad data model in production with real data in it. Once customers have been using a product and their data lives in your database, you can't just redesign the tables. You have to migrate the data, which is its own project, and you have to keep the app running while you do it. The cost of that migration often exceeds what it would have cost to design the data model correctly at the start.

A rough estimate that holds up in practice: fixing a vibe-coded codebase with structural problems typically costs more than rebuilding the core of it properly, because you're paying both for the rebuild and for the time spent understanding what was there. The only exception is when the data model is sound and the surface area of the problems is limited. That does happen, but you need someone experienced to make that call.

The other version of this is the security audit. If you're building in a regulated industry, healthcare, finance, anything that touches personal information, you will at some point need to demonstrate that your application is secure. That process on a codebase nobody fully understands is expensive. The auditor charges for their time. The fixes they require have to be made. The re-test costs more. Compare that to having someone design the security model at the start.

The cost of not knowing what's in your codebase

There's a specific category of risk that comes from having a codebase you didn't write and haven't fully reviewed.

Data breaches in Australia are notifiable under the Privacy Act if they involve personal information. The cost of a notifiable breach isn't just the reputational damage. It's the investigation, the legal advice, the regulatory process, the customer communication, and potentially the fines depending on circumstances. The Notifiable Data Breaches scheme exists because these events cause real harm to real people.

A vibe-coded app with unscoped database queries, secrets in the repository, and no audit log is a system with an unknown number of vulnerabilities. You're not in a position to know what they are, because you didn't write it and you can't fully read it. That's not the same as having vulnerabilities you're aware of and managing. It's having vulnerabilities you don't know about at all.

The honest version of this risk is: if your product handles other people's data, the cost of a breach is probably the largest single number in your true cost of ownership, and it's the one least reflected in the prototype's build cost.

The cost of debugging something you don't understand

When something breaks in a system you didn't build and don't understand, your options narrow quickly. You can feed the error back to an AI and hope it fixes it. You can try to find a developer willing to work in a codebase with no tests and no documentation. You can hire someone to do a full review before they'll touch it.

Each of these has a real cost, and none of them are fast.

The version of this that founders most often describe is: something breaks, they ask the AI to fix it, the AI fixes that specific thing, but the fix introduces a different problem, and now there are two things wrong. Without someone who understands the system, this loop is hard to exit.

It's the software equivalent of doing your own car repairs by watching YouTube tutorials and asking an AI what part to replace. Sometimes it works. When it doesn't work, you've still got a broken car, you've also spent time on it, and you've now got several things disconnected that need to be put back together correctly before a mechanic can make sense of what they're looking at.

When vibe coding is the right call

There are real situations where vibe coding is exactly what you should do.

You're testing an idea before spending real money on it. A prototype that helps you validate whether customers will pay for a thing, before you invest in building the thing properly, is exactly the right use of these tools. The point is to fail cheaply if the idea doesn't work and to have information if it does.

You're building an internal tool for a small team with no sensitive data. Internal tools have a different risk profile to customer-facing products. If the tool is only used by your team, has no personal information in it, and there's no regulatory exposure, the bar for "production-ready" is lower. A vibe-coded internal tool that works is fine.

You're building a reference implementation or demo. If the output is documentation, demonstration, or a reference for how something should look, the security model doesn't matter much.

The common thread in all of these is that the risk from the prototype's shortcomings is contained. When it isn't contained, when real customers are using it, when personal data is involved, when money is moving through it, the vibe-coded prototype's costs start becoming real.

What to do with the prototype you've got

The most common situation is a founder who built something, has some real users, maybe some paying customers, and is now looking at what it would take to take the thing seriously.

The good news is that vibe-coded prototypes aren't automatically write-offs. The frontend code from AI tools is often genuinely usable. The data itself, the records your customers created, is almost always worth keeping. The question is what the foundation looks like and whether it can be worked with.

At Code Workshop, when a founder brings us an existing build, the first conversation is a triage. Where are the credentials? Can we run it locally? What does the data model look like? Does auth actually scope to the right tenant? The answers to those five questions tell us most of what we need to know about what's salvageable and what needs to be done first.

Sometimes the answer is: the foundation is sound enough that we can build on it with some security work done first. Sometimes the answer is: the data model is wrong in ways that mean everything built on top of it is going to need to be rebuilt eventually, and the cheaper path is to do it now. Both of those are honest assessments based on what's actually there, not a judgement on what got built.

If you've built something with an AI tool and you're trying to work out what it would take to do this properly, bring us the export. We'll have a look at what you've got and give you a straight answer about what the path forward looks like.

Book a free chat with Code Workshop and bring whatever you have. A working prototype is a better starting point than a blank page.