How Long to Get a Bolt or v0 App Production Ready?

What a 14-day hardening engagement actually looks like

The four moves on the Vibe Rescue page (send the repo, we fix what is flimsy, ship it for real, hand back the keys) are accurate but compressed. The full engagement framing sits in the companion post; this is the timeline view.

Days 1–2: written audit. A senior engineer reads the repo end to end and returns a written intake: three must-fix items, two should-fix items, the parts that already work flagged for preservation. The audit is free and the 14-day clock does not start until the founder accepts the flat number.

Day 1 of the rescue proper. The project gets forked into a Cardinal-managed working copy. Auth is the first surface opened, because auth has the highest blast radius and the most downstream dependencies: every other surface eventually touches it. The operating stack gets wired in concurrently: Pulse for monitoring, Triage for feedback, Bug Catcher for runtime errors, Scout for telemetry.

Days 2–10: parallel surface work.This is where the methodology becomes visible. Six of the seven audited surfaces (data layer, secrets, AI cost ceilings, error monitoring, deploy pipeline, PII handling) run in parallel through Worktree, Cardinal's parallel-agent orchestration. Multiple agents work on isolated git worktrees against the same project, each driving a single surface, with senior engineers supervising the diffs and arbitrating anything that crosses boundaries. Sequential work that would take three to four weeks compresses into roughly seven working days because the surfaces are not waiting on each other.

Day 7: mid-engagement checkpoint. Founder sees a running staging deploy. A real URL, not a screenshot. Anything flagged here folds into the back half of the schedule.

Days 11–14: deploy window.Slow on purpose. Deploys to the founder's own domain cannot be parallelized. DNS propagation, SSL issuance, environment variable scoping, backup verification, and the rollback rehearsal all run in sequence. Day 14 is a screen-share handoff with a written runbook. The 30-day free fix window starts the next morning.

What takes the most time (and why auth is always day one)

Not every surface costs the same. Some compress well under parallelization; some refuse to. Knowing the difference is what keeps the calendar real.

Auth: 2–3 days of senior time. Auth touches every authenticated route, every session boundary, every password reset path, and every OAuth callback. Changes to bcrypt cost factors, session expiry, or the revocation table ripple into surfaces that have to be re-verified after the change. Auth runs first because everything downstream assumes auth is correct; if it is fixed last, every other surface gets re-tested. Cardinal opens day one with auth so the rest of the engagement can trust the foundation.

RLS audit across many tables: 1.5–2.5 days. Row Level Security on Supabase has to be reviewed per table, per role, per policy. The CTO read on Lovable security gaps covers the specific policy patterns in detail. A 20-table project means 20 RLS audits, and audits of vibe-coded apps routinely find significant data-exposure vulnerabilities shipping before there are any real users on the system. RLS misconfiguration is most of that surface, failing silently.

RLS misconfigurations do not throw errors. They look like the app is working, until the day they aren't.

Secret rotation: 0.5–2 days, mostly waiting. The Cardinal team can pull every secret out of git history, scope environment variables per environment, and add a pre-commit hook in a few hours. The slow part is upstream coordination: rotating an OpenAI key, a Stripe key, a Supabase service role, or a SendGrid token requires the founder to be in their accounts approving the rotations. That calendar dependency is one of the few items the engagement cannot parallelize away.

Deploy pipeline setup: 1–2 days. If the project ships with no CI gate, no preview environments, and no rollback path (which describes most Bolt and v0 builds), the deploy pipeline gets built from scratch. CI on the main branch with typecheck and build gates. Preview environments on pull requests. One-click rollback rehearsed on the host of choice. This work blocks the deploy day, so it lands in the back half of the schedule, not the parallel section.

The rest. Error monitoring wire-up runs in half a day. AI spend ceilings and per-user rate limits run in a day. PII redaction through Redactor lands in roughly a day per LLM-touching endpoint. Each of those runs in parallel against the same project, so the wall-clock cost is closer to the longest single surface than the sum.

Does Bolt vs v0 vs Lovable change the production timeline?

The 14-day timeline holds across Bolt, v0, Lovable, and Cursor. The surfaces being audited are the same. What shifts is the distribution of effort, not the total.

Bolt apps tend to be heavier on the backend layer. Bolt scaffolds the database, server logic, and API routes more aggressively than its peers, which means more state to reason about. Hardening a Bolt app for production usually spends an extra day on data layer work (schema reconciliation, migrations, access controls) and slightly less on the deploy pipeline because Bolt projects often ship with at least a minimal deploy story.

v0 apps reaching production sit at the opposite end. v0 is UI-first, so a v0 app production hardening engagement tends to find a clean component tree, well-shaped routing, and almost no backend infrastructure. Auth is usually thin because there is less authenticated state, but the data layer often does not exist yet and gets stood up during the rescue. Less audit work, more new infrastructure work, same 14 days.

Lovable apps sit in the middle. Lovable ships with Supabase by default, so the data layer exists from day one, but RLS is off on every table by default, and that is where most of the audit time goes. Auth is configured but with weak defaults. Deploys are one-click but without a rollback rehearsal. The most predictable of the four because the toolchain is the most consistent.

Cursor projects are typically further along. Cursor is hand-coded software with AI assistance, not prompt-driven scaffolding, so the codebase usually shows architectural intent. Cursor rescues need less hardening on the data layer and more on operational surfaces: monitoring, spend ceilings, deploy rollback. Saved audit time gets reinvested in deeper operational work.

The pattern across all four: the tool determines which surfaces start strong and which start weak. The total audit covers the same seven failure modes. Worktree distributes the work in parallel regardless of where the weight sits. The vibe coding production timeline holds at 14 days across all four tools.

What you get at the end of day 14

Day 14 is a handoff, not a status update. The deliverables are concrete and the ownership is unambiguous.

• A hardened production deploy at your own domain: SSL issued, CDN configured, backups running on a verified schedule, point-in-time recovery on the primary database, one-click rollback rehearsed and documented.
• The Cardinal operating stack wired into your project: Pulse for production monitoring, Triage for user feedback capture, Redactor for PII privacy on any LLM call, Bug Catcher for runtime error capture, Scout for telemetry, and Worktree retained on the codebase if you keep shipping with parallel-agent assistance.
• A written runbook covering the deploy steps, the rollback procedure, the alert routing, the secret rotation schedule, and the contact path for the 30-day free fix window.
• Full ownership of the code, the deploy, the database, and every external account. No proprietary lock-in. No Cardinal-only deploy target. You can keep building in Bolt, v0, Lovable, or Cursor after handoff. The hardening lives in config, environment variables, and a thin server layer that does not interfere with how the editor opens your project.
• Thirty calendar days of free fixes from day 14 forward. If something in the rescue scope breaks, Cardinal fixes it at no charge. Scope changes (new features, new surfaces) get quoted in writing before the work starts.

Senior humans are non-optional throughout. AI generates most of the code that flows through Worktree, but strategy, security review, regulated-compliance decisions, architectural calls, and the QA pass are handled by senior engineers. The methodology accelerates senior engineers; it does not replace them.

If you have a Bolt, v0, Lovable, or Cursor build sitting at the demo stage and you need it production ready inside two weeks, send the repo for a written audit and the written intake comes back within two business days, with a flat number and a list of must-fix items inside. No obligation to proceed after the intake.

The full operating stack (Pulse, Triage, Redactor, Worktree, Bug Catcher, Scout) ships with every engagement.