How to harden a Lovable, v0, or Bolt app for production in 14 days

Why vibe-coded apps break under real traffic

Lovable, v0, Bolt, and Cursor are excellent at the first ninety percent. They scaffold a working idea in hours instead of weeks. The trouble is the last ten percent. It is the part real users break in twenty minutes.

That last ten percent is not a design issue. It is the layer underneath: authentication, data persistence, secret management, AI cost ceilings, error monitoring, deployment pipeline, and user data handling. Those concerns rarely surface in a prompt-driven build because the model has no production context. It optimizes for the screen, not the uptime.

The failure pattern is consistent across tools and unforgiving in production. Audits of vibe-coded apps routinely find data-exposure vulnerabilities shipping before there are any real users on the system. Not bugs in the screens. Not broken interactions. Tables with Row Level Security off, API endpoints that returned other users' records, secrets committed to git history. The apps looked like they worked. They did, until the day someone curious opened the network tab.

None of this means vibe coding is a mistake. It means the handoff from prompt-driven scaffolding to public-facing software is a real engineering step, and it has a shape that does not change much project to project. Naming the shape is the first move.

The seven failure surfaces to harden first

Every Cardinal Vibe Rescue audit checks the same seven surfaces in the same order. They map to the failures that kill the most projects after launch. What follows is the diagnostic view: what breaks, what good looks like, and the question a founder can ask of their own repo before deciding whether to send it.

1. Auth. The default failure modes are bcrypt cost factors set too low, session tokens that never expire, no rate limit on the login route, password reset flows that leak whether an email exists, and OAuth callbacks that accept any redirect URL. What good looks like: bcrypt at 12 rounds or higher, sessions that expire and rotate, login rate-limited per IP and per account, generic reset responses, OAuth callback URLs validated against an allowlist. The diagnostic question: if a hostile script hit my login route 10,000 times in an hour, what would happen?

2. Data layer. Schema drift between local and production. No migrations folder, so the prod database has columns the codebase no longer references. Tables with no backup policy. No point-in-time recovery, so a bad DELETE at 11pm Saturday is permanent. What good looks like: a migrations folder under version control, daily backups with a verified restore drill, point-in-time recovery enabled on the primary database, schemas reconciled between environments. The diagnostic question: if the database disappeared right now, how much would I lose and how long would it take to come back?

3. Secret management.API keys in git history (even after a force-push, they are still cached somewhere). Environment variables shared across environments. Client-side bundles that leak server secrets. No rotation policy on third-party tokens. What good looks like: secrets stored in the host's vault not the repo, per-environment scoping, a pre-commit hook that blocks new secrets from entering git, a written rotation schedule for tokens that have ever been exposed. The diagnostic question: if I made my repo public tomorrow, what would I have to rotate first?

4. AI cost ceilings. No spend cap on the OpenAI or Anthropic key. No per-user or per-endpoint rate limit on chat features. No abuse detection. One scripted user calling a chat endpoint in a loop overnight is a four-figure bill by morning. What good looks like: a hard monthly spend cap on every AI provider, per-user rate limits on every LLM-touching route, a kill-switch on the spend dashboard, and alerts at 50/75/90 percent of cap. The diagnostic question: what is the absolute most I can be billed this month if someone tries to drain my key?

5. Error monitoring. console.logand nothing else. Errors surface when users complain on Twitter, not when they happen. No alert on a 500-spike. No correlation between a deploy and a regression. What good looks like: Sentry or equivalent wired on both client and server, alerts routed to a place the founder actually reads (Slack, email, SMS), release tags on every deploy so regressions get attributed to the change that caused them. The diagnostic question: if a critical bug shipped at 3am, when would I know?

6. Deployment pipeline. Manual deploys from a laptop. No preview environments. No rollback button. No CI gate on the main branch, so a typo can take the site down. What good looks like: deploys triggered by a tagged commit on a protected branch, preview environments on every pull request, a one-click rollback rehearsed at least once, typecheck and build gates running in CI before merge. The diagnostic question: if the deploy I just shipped is broken, how do I get back to the last good version, and how long does it take?

7. User data handling.PII flowing through prompts to LLMs unredacted (a HIPAA, GDPR, and common-sense problem at once). Weak access controls, so a request signed in as user A returns user B's records. No audit trail on who accessed what. What good looks like: a redaction layer between the app and any LLM, row-level access controls verified per route, an append-only audit log on sensitive data reads, written data-handling posture the team can produce on request. The diagnostic question: if a regulator asked me to prove no patient name has ever been sent to OpenAI, could I?

A vibe-coded app rarely fails with a stack trace. It fails by quietly answering questions the user was never supposed to be able to ask.

Audit first, rebuild almost never

Most Lovable, v0, and Bolt projects do not need a rewrite. The screens are usually fine. The data flow is usually fine. The interaction patterns are usually fine. The fixes live in the layer users never see, and rewriting the parts that already work is how rescues turn into year-long re-engagements that the founder did not ask for.

The rebuild temptation is real and worth naming. A senior engineer reading a Lovable codebase for the first time often wants to throw out the file structure, replace the styling approach, swap the form library, and rename half the components. Those are aesthetic preferences disguised as engineering work. The founder pays for them. The user does not benefit. Cardinal's default posture is to preserve the surface area the founder built and replace only the invisible plumbing.

That is why every engagement opens with a written audit, not a discovery call. Send the repo. Two business days later, you get a written intake with three must-fix items, two should-fix items, and the parts that already work flagged for preservation. The flat number is at the bottom of the intake. If the quote works, we start. If the code turns out to be in better shape than expected and there is no rescue to run, you keep the audit at no cost and a written production-readiness report for your records.

The audit is also the place where a project gets quoted out of Vibe Rescue and into a Flagship Build instead. If the audit reveals that the architecture is fundamentally broken, or that a missing data layer needs to be designed from scratch, or that the regulatory posture requires more than two weeks of compliance review, the intake says so and quotes the larger engagement. The audit is free in either direction.

The 14-day production plan, from the founder's side

Cardinal's Vibe Rescue ships in fourteen calendar days, $4,800 flat. The day-by-day mechanics of how a senior team parallelizes the seven surfaces across that window are in the timeline post (Kanji writes the operational view). What follows is the shorter founder-side view: what the founder is doing on each phase of the calendar, since the engagement is not zero-touch.

• Days 1–2. Free written audit. The founder sends the repo, fills a short intake form, and waits. That is all. Two business days later the written audit comes back. The founder reads it, decides, and either accepts the flat number or keeps the audit and walks.
• Days 3–10. Parallel surface work. The founder is on a daily async update over whatever channel they prefer (Slack, email, Loom). The only synchronous ask is upstream secret rotations: at some point in this window, the founder logs into OpenAI, Stripe, Supabase, and any other third-party account to rotate exposed tokens. That work is twenty minutes total spread across the week.
• Day 7. Mid-engagement checkpoint. The founder gets a working staging URL and a request for feedback. Anything flagged here folds into the back half of the schedule, no scope-change ticket.
• Days 11–13. Production deploy window. The founder confirms the production domain, signs off on the DNS records, and approves the cutover window. The deploy itself is a sequence the Cardinal team runs; founder time on these days is roughly an hour total.
• Day 14. Handoff. A scheduled screen-share walks through the new deploy, the rollback procedure, the alert routing, and the runbook. The founder leaves the call with the credentials, the runbook, and a calendar invite for the 30-day free fix window check-in.

The fourteen-day timeline is the calendar from accepted audit to handoff. The audit itself sits in front of it, free, and the 30-day free fix window sits behind it, included.

What we keep, what we replace

We rescue, we do not rebuild. The default posture is to preserve your screens, your component tree, your data shapes, and your editor of choice. We work on a copy of the project and merge our hardened changes back. You can keep building in Lovable, v0, Bolt, or Cursor after the rescue ships, and the hardening lives in config, environment variables, and a thin server layer that does not interfere with how the editor opens your project.

The concrete kept-versus-replaced split:

• Screens and components: kept. Your routes, page layouts, design system, and interaction patterns stay as written. We add accessibility fixes where they are missing and standardize loading and error states, but the surface area is yours.
• Data shapes: kept, indexed. Your tables, columns, and relationships stay. We add the migrations folder, the RLS policies, the audit columns, and the backup schedule. The shape of the data does not change; the policies around it do.
• Auth flow: kept, hardened. If you have email/password auth, you keep email/password auth. If you have Google OAuth, you keep Google OAuth. The hashing rounds, session policies, rate limits, and callback validation get replaced underneath.
• Secrets and config: replaced. Every secret that has ever touched git gets rotated. Every environment variable gets scoped per environment. The pre-commit hook gets added. The repo gets a clean .env template that does not leak shape.
• Deploy pipeline: replaced. Manual deploys from a laptop are out. Tagged-commit deploys with preview environments, CI gates, and a one-click rollback are in. If your project ships on a host that supports those workflows, we keep the host. If it does not, we move it and document why.
• AI plumbing: replaced. Direct LLM calls from the client are out. Server-side calls with rate limits, spend ceilings, and PII redaction are in. Every prompt that touches user data passes through Redactor before the network call.
• Monitoring layer: added. Sentry, the Cardinal Pulse uptime probe, the Bug Catcher runtime error sink, and Triage for user feedback all get wired into a project that almost certainly had none of them. The dashboards are yours from day one.

What you can fix this weekend without us

Not every project is a Vibe Rescue candidate, and not every founder wants to outsource the hardening step. Three of the seven surfaces are realistically a weekend of work for a founder who is comfortable in their own codebase. Doing them first is the right move whether or not you ever send the repo.

Saturday morning: rotate every secret that has ever touched git. Run a tool like gitleaksor trufflehogagainst the full repo history. For every key it finds, rotate the upstream token in the provider's dashboard (OpenAI, Anthropic, Stripe, Supabase, SendGrid, anything else). Move the new tokens into your host's environment-variable vault, not .env committed to the repo. Add a pre-commit hook that blocks new secrets from being committed. The work is two to three hours and it removes the worst class of post-launch incident.

Saturday afternoon: turn on Row Level Security on every Supabase table. If you are on Lovable or Bolt with Supabase, log into the dashboard and check the RLS status on every table. Default-deny is the correct posture: deny all access, then add per-role policies that explicitly allow the reads and writes the app needs. The Supabase docs walk through the policy syntax. This is the single highest-leverage afternoon a Lovable-built founder can spend before launch.

Sunday: wire Sentry.Sign up, install the SDK on the client and the server, set the alert routing to your phone or your Slack, and tag releases so you can see which deploy a new error came from. The free tier is usually enough for a pre-launch app. The total work is under an hour and it turns "errors I learn about from users" into "errors I learn about before users do."

What you should not try to fix on a weekend: the architectural ones. AI spend ceilings depend on the provider's rate-limit API and a server-side middleware that has to be designed, not configured. PII redaction is hard to get right without a redaction library and a test suite. The deploy pipeline is real infrastructure work. Those are the four surfaces a Vibe Rescue earns its fee on. The three above are not.

Next step: free 48-hour audit

Send the repo. Get a written production-readiness report back in two business days. Free, mutual NDA, no commitment. Start at the Cardinal Stacks diagnostic page.