What Does It Cost to Make a Vibe-Coded App Production-Ready?

You shipped a product with Lovable, Cursor, or Claude Code in a weekend, and now someone wants to pay for it. The next question is the one nobody priced into the prototype: what does it cost to make this safe to run? This post is about money and time, not about whether vibe-coding was a mistake. It was not. It got you here. The bill for the parts the model skipped is just arriving now.

The numbers here are ranges from Wavect's engagement history on AI-generated code, framed as typical, not as a quote. Anyone who hands you a precise figure for a codebase they have not seen is guessing, and the guess is always optimistic. We scope after a first look.

What are you actually paying for?

You are not paying to rewrite working software. You are paying for the work the prompt never asked for: the authorization the model left in the frontend, the secrets it inlined to make the example run, the queries that are fine with ten rows and fatal with a hundred thousand. None of that shows in a demo. All of it shows on launch day. The cost of a production-ready pass is the cost of finding and closing that gap before a user finds it for you.

The work splits into two phases, and they price differently. The first is the audit: a structured read to find what is hiding. The second is the hardening: fixing what the read turned up. Most of the time and money is in the second, but the first is what tells you how big the second is.

What does the audit itself cost?

An audit is the cheap part, and it is the part that buys you certainty about everything else. It runs from a few days to about a week of focused work, depending on how big the codebase is and how much real money or sensitive data it touches. A read-only internal tool sits at the short end. A product that takes payments and holds personal data sits at the long end, because those are exactly the parts that need the closest read. The deliverable is a findings report sorted by severity and an honest estimate of the hardening that follows. You can read what an audit actually finds in our vibe-coded software audit writeup.

What does the hardening cost?

This is where the real spend lands, and it scales with what the audit found. The honest way to talk about it is in bands, because two products with the same feature list can need very different work depending on what the model left behind.

Treat these as directional. The variance inside each row is driven by two things: how much real money or sensitive data the product touches, and how far the AI ran without anyone steering it. A weekend prototype that handles payments and personal data needs more than a weekend of QA.

Where does the time actually go?

People expect the bill to be dominated by writing new code. It is not. On a typical vibe-coded hardening pass, the rough split looks like this.

• Reading and reproducing, 20 to 30%. Understanding what the model built and reproducing the failures before touching anything. You cannot fix what you have not confirmed is broken.
• Authorization and data access, 25 to 35%. Almost always the single largest line. Moving access checks off the frontend and onto the server, and isolating tenants at the database layer, is slow, careful work because it touches every endpoint.
• Failure paths, validation, secrets, 15 to 25%. The unglamorous middle. Error handling on every external call, input boundaries, and getting keys off the client and rotated.
• Tests and a regression suite, 15 to 20%. Writing the tests the prototype never had, so the next change does not undo this one.

The pattern that surprises founders: the new feature work is usually the smallest slice. The expensive part is the invisible infrastructure that a demo never exercises.

"The cost of making vibe-coded software safe is not the cost of rewriting it. It is the cost of the work the prompt never asked for, and that work did not disappear because a model wrote the first draft."

What does the audit typically find?

The findings cluster, which is what makes them estimable. Across vibe-coded builds, the same items surface again and again: a working login with no server-side check stopping user A from reading user B's data, secrets in the client bundle, no error handling off the happy path, queries that collapse at scale, and no tests at all. The full breakdown of what breaks and how we sort it by severity is in our QA for AI-generated code post, and the step-by-step migration work is in from Lovable and Cursor prototype to production.

What is the cost of not doing it?

This is the comparison that matters. A hardening pass is a known, scoped, one-time cost. The alternative is an unknown cost paid at the worst possible moment. A leaked payment key is not a line item, it is an incident. A missing authorization check is not a bug, it is a data breach with regulatory and reputational tails. The honest framing is not "an audit costs money," it is "an audit is cheap insurance against finding the same gaps the hard way, after the incident instead of before it."

When is a rebuild cheaper than hardening?

Sometimes the read shows the core itself is wrong: a data model that cannot hold what the product needs, or the same broken pattern copied across the whole codebase so every fix has to be made a hundred times. When that happens, rebuilding the core is cheaper than patching it forever, and we will say so on the first call rather than bill you to patch a foundation that needs pouring again. Patching a foundation that needs to be poured again is the most expensive way to save money.

How does Wavect price this work?

We use agile fixed price once the audit has removed the biggest unknowns. The audit is scoped tight and small. The hardening is scoped from what the audit found, with blockers, highs, and cleanup separated so you decide what to fund and when. You are never asked to sign a fixed figure for work nobody has looked at yet. This is the front end of our software quality assurance service.