How Long Does It Take to Make a Vibe-Coded App Production-Ready?

Usually there is a date attached to this question. A demo, a pilot customer, a cohort of users you promised access to, an investor who wants to see the thing running. You need to know whether hardening the app takes a weekend or a quarter.

Industry-wide, rescue engagements run four to ten weeks. That range is real but unhelpfully wide, because most of what determines where you land is decided in the first three days.

Here is what the calendar actually looks like.

The phase map

An app with no payments, no live users, and a sane data model finishes in two to three weeks. An app with paying customers, a compliance ask, and a data model that needs surgery is a seven- to ten-week engagement. Most land in the four-to-six-week middle.

Week one is not fixing, and that is deliberate

Founders often expect work to start with commits. It starts with reading. In the first two to five days a competent team is doing four things: enumerating every secret in the repo and in the deployed bundle, testing whether one user's session can read another user's data, tracing what happens to each external API call when it fails, and checking whether the database can even represent the states your product needs.

That week produces a prioritized list, not a patched app. It feels slow and it is the highest-leverage part of the schedule, because everything after it is scoped instead of exploratory. Our AI code audit guide covers what a proper pass includes and what it should hand back.

Skipping the audit does not save a week. It moves the discovery into the middle of the fix work, where each surprise stops progress instead of shaping the plan.

Where the weeks actually go

Live production data

This is the single biggest multiplier. With no users, a bad schema gets replaced in an afternoon. With five thousand rows of real customer data and no migration history, every change becomes a three-step dance: add the new shape, backfill, cut over, verify, drop the old. Plan for 30 to 50 percent more calendar time on every data-touching task, and for the work to be done in smaller, reversible slices.

Payments

Stripe wired into a vibe-coded app is almost never finished. Webhook signature verification, idempotency keys so a retried event does not double-charge, refund and dispute paths, and reconciliation between your database and Stripe's are all standard omissions. Budget an extra week if money moves through the product, and expect a chunk of it to be spent in test mode reproducing the failure cases nobody triggered by hand.

Whether anything must be rebuilt

Most rescues are repairs. But if the data model cannot express your actual product — no tenant boundary, no way to represent a subscription lifecycle, everything denormalized into one wide table — you are looking at replacing a subsystem, not patching it. That decision is made in the audit and it is worth making explicitly rather than discovering it in week four. The trade-offs are laid out in rebuild or harden.

Compliance obligations

SOC 2, HIPAA, or GDPR change the definition of done from "it works and it is safe" to "it works, it is safe, and we can prove it." Evidence, audit trails, access reviews, and documented processes take weeks that engineering alone does not.

How fast you answer questions

An unglamorous one. Rescue work generates decisions only the founder can make: which of these three behaviors is correct, is this half-built feature staying, whose data is this. Teams that answer within hours finish noticeably sooner than teams that answer weekly.

What ships when

You do not have to wait until the end to be safer. A sensible engagement puts the highest-risk fixes first, so by end of week two the exposed keys are rotated, access rules are enforced, and the app can no longer leak. Reliability, performance, and polish land after that. If your launch date is fixed, this ordering means you can ship on a partially hardened app with a known list of remaining items, rather than gambling on an unknown one.

That ordering is also why fixed-scope engagements beat hourly ones for this work — the phases are predictable enough to price, and the incentives point the right way. We make that argument in why a rescue should be fixed-scope.

Timelines that should worry you

A team promising a full hardening pass in three days has not read the code. A team that cannot give you any estimate after an audit either did not do the audit or does not want to be held to it. And an open-ended hourly engagement with no phase boundaries tends to expand to fill whatever budget exists.

The useful shape is: fixed-price audit, then a phased plan with dates and a defined list per phase, then work. If you want to know what the plan should be measured against, the production readiness checklist is the list we run against, and what a rescue costs covers the money side of the same decision.

Frequently asked questions

Can I keep shipping features while the hardening happens? Yes, with one rule: feature work goes through the same review as the fix work. The failure mode we see most is a founder prompting new features into the app in parallel, which reintroduces the patterns being removed and creates merge conflicts in code nobody has tests for. Agree on a freeze for the areas under repair and ship elsewhere.

How long until the app is safe, as opposed to finished? Usually one to two weeks. Secret rotation and access control are front-loaded precisely because they are the fixes that stop an active bleed. Everything after that is about the app surviving growth rather than surviving today.

Does the builder I used change the timeline? Somewhat. Tools that hand you a real repository start at day zero; platforms with proprietary runtimes add an export and re-platform step before hardening begins. Agentic editors like Cursor or Claude Code skip the export problem but often carry more architectural drift, which lands in the middle phases instead.

---

If you are working toward a launch date and need to know whether the app will be ready for it, that is an answerable question rather than a hope. SprintX audits AI-built apps in under a week and returns a phased plan with dates you can plan a launch around. Send us the repo or builder link.