--- title: "Vibe-Coded App to Production-Ready: What It Costs" canonical: https://wavect.io/blog/vibe-coded-software-audit-cost/ language: en description: "What it costs to make a vibe-coded app production-ready, what an audit typically finds, and effort bands by product type. Typical ranges from Wavect, not quotes." image: "https://wavect.io/img/blog/headers/header_vibe-coded-software-audit-cost.png" --- [**Back**](/blog/overview/) [![Christof Jori](/img/team/christof.webp)](/team/christof-jori/) [Christof Jori](/team/christof-jori/) https://linkedin.com/company/wavect 8 min read · 16 Jun 2026 Last reviewed August 7, 2026 [**Next**](/blog/vibe-code-production-readiness-checklist/) # What Does It Cost to Make a Vibe-Coded App Production-Ready? TL;DR Making a vibe-coded app production-ready means funding the work the prompt omitted. Start with an audit lasting a few days to roughly a week, then scope hardening from the evidence. Wavect usually finds the largest risks in authorization, tenant isolation, data access, secrets, migrations, observability, and recovery, not missing features. The time ranges in this guide are directional engagement history, not quotes. If core boundaries are unsafe, rebuilding a narrow foundation can cost less than repeatedly patching it. Related service: [Vibe Coding Rescue](/services/vibe-coding-rescue/) 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](/glossary/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](/glossary/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](/glossary/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](/blog/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. | Product type | Typical effort | What drives it | | --- | --- | --- | | Read-only internal tool | A few days | No payments, no PII, low blast radius | | Single-tenant app, light data | About one to two weeks | Auth and validation gaps, error handling, secrets | | Multi-tenant SaaS with payments | Two to four weeks | Row-level isolation, payment idempotency, load, observability | | Core rebuild needed | Re-scoped as a build | Broken data model or one bad pattern copied everywhere | 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](/glossary/vibe-coded-software/) 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. ![Christof Jori](/img/team/christof.webp) "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](/blog/qa-for-ai-generated-code/) post, and the step-by-step migration work is in [from Lovable and Cursor prototype to production](/blog/lovable-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](/glossary/agile/) [fixed price](/glossary/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](/services/software-quality-assurance/). ## Final thoughts Making a vibe-coded app production-ready is not expensive because the code is bad. It is the predictable cost of the weeks of hardening that every production system needs, and that the prototype skipped. That cost did not vanish because the first draft was fast. It moved to launch day, where it is most expensive to discover. The good news is that it is knowable. An audit of a few days tells you the size of the hardening before you commit to it, sorts the work by what actually blocks a launch, and turns an open-ended worry into a scoped number. Get the read first. The number you fear is almost always smaller than the incident you are insuring against. ## You may also like.. [**The Vibe-Code Production-Readiness Checklist** A standalone, scannable checklist to run on any AI-generated app before you put real users on it.](/blog/vibe-code-production-readiness-checklist/) [**Vibe-Coded Software Audit** What a structured read of AI-generated code actually finds, sorted by what blocks launch versus what can wait.](/blog/vibe-coded-software-audit/) ## Primary sources used in this audit guide The effort bands are Wavect planning ranges. These standards define the security and software-supply-chain work an audit should test. - [NIST Secure Software Development Framework](https://csrc.nist.gov/projects/ssdf) - [OWASP Application Security Verification Standard](https://owasp.org/www-project-application-security-verification-standard/) - [SLSA specification 1.2](https://slsa.dev/spec/v1.2/) QA and production readiness ## Continue through this cluster Testing, audits, maintenance and hardening practices for reliable production software. [Start with the cornerstone**QA for AI-Generated Code**](/blog/qa-for-ai-generated-code/) - [Agentic Testing vs Test Automation: 2026 Pilot Guide](/blog/agentic-testing-vs-test-automation-2026/) - [External QA Benchmark: What We Find in the First 30 Days](/blog/external-qa-benchmark-first-30-days/) - [What Software Maintenance Costs After Launch: A DACH SaaS Benchmark](/blog/software-maintenance-cost-benchmark-dach-saas/) - [Agile De-engineering](/blog/agile-de-engineering/) - [Lovable, Bolt, and Replit App Due Diligence](/blog/lovable-bolt-replit-app-due-diligence/) Inbox, without the noise ## Follow the work that matters to you Get a short email when we publish something new. Follow the whole blog or only the problems you care about. [**Back**](/blog/overview/) [![Christof Jori](/img/team/christof.webp)](/team/christof-jori/) [Christof Jori](/team/christof-jori/) https://linkedin.com/company/wavect 8 min read · 16 Jun 2026 Last reviewed August 7, 2026 [**Next**](/blog/vibe-code-production-readiness-checklist/) New posts by email × × Get new posts by email A short email when we publish. Free, no tracking. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/blog/vibe-coded-software-audit-cost/#webpage", "@type": "WebPage", "dateModified": "2026-07-07", "inLanguage": "en", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-07-07", "url": "https://wavect.io/blog/vibe-coded-software-audit-cost/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "Making a vibe-coded app production-ready means funding the work the prompt omitted. Start with an audit lasting a few days to roughly a week, then scope hardening from the evidence. Wavect usually finds the largest risks in authorization, tenant isolation, data access, secrets, migrations, observability, and recovery, not missing features. The time ranges in this guide are directional engagement history, not quotes. If core boundaries are unsafe, rebuilding a narrow foundation can cost less than repeatedly patching it.", "articleBody": " Blog overview/Delivery and QA/QA and production readiness What Does It Cost to Make a Vibe-Coded App Production-Ready? TL;DR Making a vibe-coded app production-ready means funding the work the prompt omitted. Start with an audit lasting a few days to roughly a week, then scope hardening from the evidence. Wavect usually finds the largest risks in authorization, tenant isolation, data access, secrets, migrations, observability, and recovery, not missing features. The time ranges in this guide are directional engagement history, not quotes. If core boundaries are unsafe, rebuilding a narrow foundation can cost less than repeatedly patching it. Related service: Vibe Coding Rescue 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. Product type Typical effort What drives it Read-only internal toolA few daysNo payments, no PII, low blast radius Single-tenant app, light dataAbout one to two weeksAuth and validation gaps, error handling, secrets Multi-tenant SaaS with paymentsTwo to four weeksRow-level isolation, payment idempotency, load, observability Core rebuild neededRe-scoped as a buildBroken data model or one bad pattern copied everywhere 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", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/" }, "citation": [ { "@type": "WebPage", "name": "NIST Secure Software Development Framework", "url": "https://csrc.nist.gov/projects/ssdf" }, { "@type": "WebPage", "name": "OWASP Application Security Verification Standard", "url": "https://owasp.org/www-project-application-security-verification-standard/" }, { "@type": "WebPage", "name": "SLSA specification 1.2", "url": "https://slsa.dev/spec/v1.2/" } ], "dateModified": "2026-08-07", "datePublished": "2026-06-16", "description": "Making a vibe-coded app production-ready means funding the work the prompt omitted. Start with an audit lasting a few days to roughly a week, then scope hardening from the evidence. Wavect usually finds the largest risks in authorization, tenant isolation, data access, secrets, migrations, observability, and recovery, not missing features. The time ranges in this guide are directional engagement history, not quotes. If core boundaries are unsafe, rebuilding a narrow foundation can cost less than repeatedly patching it.", "headline": "What It Costs to Make a Vibe-Coded App Production-Ready", "image": "https://wavect.io/img/blog/headers/header_vibe-coded-software-audit-cost.svg", "inLanguage": "en", "mainEntityOfPage": { "@id": "https://wavect.io/blog/vibe-coded-software-audit-cost/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/blog/vibe-coded-software-audit-cost/", "wordCount": 1638 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/", "name": "Home", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/blog/overview/", "name": "Blog overview", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/blog/topics/delivery-qa/", "name": "Delivery and QA", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/blog/clusters/qa-production/", "name": "QA and production readiness", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/blog/vibe-coded-software-audit-cost/", "name": "Vibe-Coded App to Production-Ready: What It Costs | ", "position": 5 } ] } ```