Vibe-Code Rescue & Production Hardening
Your AI built it fast.
I make it safe to launch.
AI tools let anyone ship an app in a weekend. The trouble starts the moment the prototype stops being a prototype — real users, real data, and real traffic hit code that was only ever tested on the happy path. That gap between “it runs” and “it's safe to run” is exactly what I fix.
The problem, in five steps
Scroll to watch it break — then get rescued
1 · AI builds it in a weekend
Lovable, Bolt, Cursor, v0, Replit, FlutterFlow — layers get stacked fast and the demo looks finished.
2 · Real users arrive
Real data and real traffic hit code that was only ever tested on the happy path.
3 · The cracks open
Auth holes. Secrets in the bundle. Non-idempotent payments. World-readable tables. Each AI fix breaks something else — the vibe cycle.
4 · I harden it
I re-architect the fragile core, seal the holes, and add the auth, payments, security, and observability the AI skipped — without a rewrite.
5 · Production-grade
Code that survives the week it gets traction. You keep your code and your stack.
Interactive security lab
A working demo can hide a broken trust boundary.
Choose a risk, trigger a synthetic event, then apply safeguards and replay it. See why payments, data and permissions need independent checks.
Choose a scenario
Checkout price tampering
A polished checkout still trusts a price sent by the browser.
Browser → pricing service
Implementation notes
Authorize an order against a trusted catalog. Client values can express intent, but cannot set the money owed. Recheck discounts and currency on the server. This fixture combines price tampering with an unsupported product selection.
A success page is not payment proof
The interface says “paid” before a trusted payment event exists.
Return URL → entitlement store
Implementation notes
A redirect is navigation, not evidence. Resolve the order server-side and confirm its owner, amount, currency and payment state. Delayed payment methods need pending states. Refunds and disputes need explicit entitlement policies.
Forged and repeated webhooks
An event endpoint trusts a payload and grants access twice.
Payment provider → webhook → records
Implementation notes
Provider events may be duplicated or arrive out of order. Authenticate the raw request before parsing business meaning. An event ledger must survive parallel delivery; a read-then-write flag is insufficient. Verify the order as well as the event.
Self-assigned administrator
An editable profile field becomes a permission.
Profile → trusted identity → protected API
Implementation notes
Authentication identifies a caller; authorization determines what they may do. Hidden controls do not protect APIs. Reject privileged profile fields and evaluate permissions at the action boundary, including background tasks.
Another customer’s invoice
A changed record identifier crosses an organization boundary.
Session → tenant → record
Implementation notes
Use two ordinary accounts in distinct organizations. Test direct records, lists, exports and writes. Never accept a tenant identifier as proof of membership. Administrative database clients bypass rules and require explicit server checks.
Public records and private files
Database rules and upload permissions are separate boundaries.
Anonymous visitor → database and storage
Implementation notes
Securing tables does not secure object storage. Review listing, download, upload and signed URL expiration separately. A public client identifier is not an administrator secret; broad policies are the vulnerability in this fixture.
An exposed key stays dangerous
Removing a secret from the browser does not revoke an earlier copy.
Public bundle → privileged service
Implementation notes
Inspect built assets and repository history. Keep privileged keys on the server with least privilege. Removing a file is not revocation. Source maps are not intrinsically secret: review their contents rather than claiming every source map is a vulnerability.
Untrusted uploads and rendered content
A file label and formatted text are accepted without validation.
Upload → server validation → rendering
Implementation notes
Browser validation is a convenience. Validate on the server and treat filenames, MIME declarations and generated content as untrusted. A URL-fetch feature also needs separate network restrictions. This fixture does not execute any uploaded content.
Unlimited requests and AI costs
A public endpoint has neither request limits nor spending limits.
Public API → workload budget
Implementation notes
Rate limits and quotas answer different questions: how quickly and how much. Apply controls before model calls or costly jobs. Distributed deployments require shared counters and a defined failure policy. Do not trust a browser cooldown.
Two purchases, one credit
Parallel requests both pass a non-atomic balance check.
API → credit ledger → fulfillment
Implementation notes
An idempotency key does not replace balance correctness, and a transaction does not identify a retried logical purchase. Test parallel requests at the boundary with one credit remaining. Commit the ledger and business state consistently.
A document asks for a customer export
Untrusted instructions steer a tool toward sensitive data.
External document → agent → authorized tool
Implementation notes
A prompt filter cannot guarantee tool authorization. Separate trusted instructions from retrieved content, constrain tool arguments and outbound destinations, and bind approvals to the exact action. This simulation illustrates an export within a scoped workflow that still requires approval.
A risky release with no signal
A release bypasses dependency checks and administrator failures go unnoticed.
Release pipeline → runtime → monitoring
Implementation notes
A scanner finding needs context and remediation ownership. An alert is useful only when someone can act on it. Protect logs from secrets and excess personal data. Monitoring detects and supports response; it does not automatically remove every vulnerability.
The numbers behind the pitch
This isn't a hunch. It's measured.
Founders don't fail because the idea was bad — they fail because the build collapses the week it gets traction. Independent studies in 2025 put hard numbers on exactly where AI-built code breaks.
~45%
of AI-generated code introduced an OWASP Top 10 vulnerability
Veracode, 2025 (100+ models tested)
86%
of relevant samples failed to defend against cross-site scripting
Veracode, 2025
Unchanged
security stayed flat across 100+ models — bigger, newer models did not write safer code
Veracode, 2025
How much more often AI code breaks
Issues in AI-written code vs human-written code, by category. Anything past the dashed line is worse than a human would ship.
Source: CodeRabbit, “State of AI vs Human Code Generation” (Dec 2025, 470 real PRs)
Share of AI code that failed security tests
Percentage of samples that introduced an OWASP Top 10 flaw, by language. The dashed line is the all-code average.
Source: Veracode, 2025 GenAI Code Security Report (100+ models tested)
And it isn't getting fixed on its own. Across 100+ models of every size and vintage, Veracode found security performance stayed flat — newer, larger models write more functional code, not safer code. The judgment that keeps an app from leaking data on day one still has to come from an engineer.
The signature diagnostic
The 10-Point Production-Readiness Audit
Each domain has what I check — and what typically breaks in vibe-coded apps. You get a severity-ranked report with a Production-Readiness Score, evidence per finding, and a prioritized fix plan.
- 01
Auth & access control
Breaks: Missing checks on protected routes; users able to act as other users.
- 02
Row-level security & data access
Breaks: Tables left world-readable/writable; RLS never enabled — the #1 vibe-coded data leak.
- 03
Secrets & config
Breaks: API keys exposed in the client bundle or extractable from the compiled app.
- 04
Payments & webhooks
Breaks: Unverified webhook signatures, no idempotency, race conditions — fake “paid” events and double charges.
- 05
Input validation & error handling
Breaks: Malformed input, empty states, and failures crash the app or corrupt data.
- 06
Concurrency & scale
Breaks: N+1 queries, missing indexes, no rate limiting — slows to a crawl or falls over.
- 07
Security (OWASP Top 10)
Breaks: Injection, XSS, broken access control, insecure dependencies.
- 08
AI surface (OWASP LLM Top 10)
Breaks: Prompt injection, data exfiltration, unbounded model cost — jailbreaks and runaway bills.
- 09
Observability
Breaks: No logging, error tracking, or alerts — you hear it's down from a user, not a dashboard.
- 10
Architecture & build health
Breaks: The vibe-cycle tangle — no one can change anything without breaking something else.
From audit to production-grade
Start with an assessment and a practical fix plan. The audit fee is credited toward your rescue if you proceed.
01
Production-Readiness Audit
Full 10-point diagnostic + written report with severity-ranked findings and a fix plan.
$500–$900
2–3 days
Credited toward a rescue.
02
Rescue Sprint
Fix the criticals — auth, payments, security, the show-stoppers.
$2,500–$5,000
1–2 weeks
03
Full Hardening
Re-architect the fragile core; add scaling, tests, and observability. Production-grade.
From $6,000
3–5 weeks
04
Care Plan
Ongoing monitoring, fixes, and safe feature work so it stays healthy.
$1,500–$3,000/mo
Ongoing
Common questions
Can't I just ask the AI to fix it?
That's the vibe cycle — each fix introduces a new bug because nothing reviews the whole system. Production needs judgment the model doesn't have.
Isn't it cheaper to rebuild?
Usually not. The audit shows exactly what's salvageable, so you fix what's fragile and keep what works — far cheaper than a rewrite.
Will you lock me into your stack?
No. You keep full ownership of your code and your tools. I make your stack production-grade.
How do I know it's actually broken?
The assessment tests agreed flows and records evidence. The initial call scopes that work; it is not a live penetration test.
Get it audited before you scale
If you vibe-coded something and you're about to launch, start with a fixed-price Production-Readiness Audit. It's credited toward your rescue. The first call helps us agree on the scope and access needed for an evidence-based review.
Vibe-Code Rescue & Production Hardening
It works in the demo.
Then real users arrive.
AI tools ship a prototype in a weekend — then it breaks the week it gets traction. Auth has holes, secrets leak into the bundle, payments aren't idempotent, and every AI fix breaks something else. I take apps from Lovable, Bolt, Cursor, v0, Replit, and FlutterFlow and make them production-grade — the auth, payments, security, and architecture the AI skipped. You keep your code and your stack.
Build fast → cracks under real users → hardened to production-grade.