Vibe coding isn't bad. It's incomplete.
Founders ship working prototypes in a weekend. Lawyers build case-intake tools without an IT department. Healthcare founders show clickable demos to investors before the slides are finished. The first 80% feels like magic. We're not arguing with that.
We're arguing about what happens between the demo and a real user logging in.
This is the audit log from one rescue. The client received what was pitched as a "Phase 1 MVP Complete" handoff from a previous developer. We were called in to take it the rest of the way. We spent three days reading the codebase before writing a single line of new code. Here is what was actually there, what we did about it, and what the math worked out to.
The project is masked as the DEA Compliance Platform on this site. The numbers are real.
What 3 Days of Audit Found
The handoff was marketed as production-ready. Here is the line-item state of the codebase the founder paid for.
No new user could register
Authentication had a circular dependency. Passkey registration required an authenticated session. Creating an authenticated session required a registered passkey. There was no path through the loop. The login screen worked for the developer's local test account because that account had been created by hand in the database. For every other person on earth, the app rejected registration before any code ran.
This was the first thing we found. Not in week three. In the first hour of the audit.
61 TypeScript errors. 8 to 10 of them runtime-critical
The codebase compiled, technically. The CI pipeline that was supposed to fail on type errors did not exist. Of the 61 errors, 8 to 10 were not cosmetic. They corresponded to runtime crashes in core flows: witness session completion, certificate generation, voice verification handoff. Users would have hit them within minutes of any real workflow.
The handoff documentation said "TypeScript strict mode enabled."
Six monolithic page files. The largest was 1,339 lines
Every page in the application was one file. HTML, business logic, state management, API calls, validation, error handling. All inline. The largest single file was 1,339 lines. Refactoring any feature meant editing a file that touched three other features.
This is the shape AI-generated code takes when nobody tells it to decompose. The model produces what it has seen most often: working CRUD pages in tutorial blog posts, where the entire page is a single component because the tutorial is one page long. At project scale, the pattern collapses.
All external integrations were stubs returning true
This is the most expensive line in the audit.
The handoff included voice biometric verification, email notifications, document storage, and PDF certificate generation. None of those integrations existed. Every one was a function signature with a hardcoded return value. Voice biometric verification returned { verified: true, confidence: 0.95 } regardless of input. Email notifications logged to console. Document uploads accepted the file and discarded it. PDF generation returned a placeholder string.
The demo flowed end-to-end because every external dependency was faked. The production app would have refused to do anything real on day one.
Zero infrastructure
No hosting. No database. No file storage. No email service. No CI/CD pipeline. No environment configuration. No deployment runbook. No monitoring. No error tracking. No DNS. No SSL certificate.
The handoff was source code in a git repository. The founder had paid for an MVP and received the equivalent of a script that had never been deployed anywhere.
Missing service methods
Witness sessions could not complete. The frontend called completeWitnessSession(); the backend route existed; the service method the route called did not exist in the service layer. The code shipped because TypeScript on the backend was not configured to error on the missing method. Anything beyond a happy-path demo crashed.
The handoff document said "Phase 1 MVP Complete." The audit notes said "no path to register a user, no path to complete a session, no integrations, no infrastructure, no production configuration." Both documents were technically about the same codebase.
What We Did About It (~120 hours, 8 weeks)
The rebuild ran about 120 engineering hours over 8 weeks, two AI-native developers. Two weeks of critical fixes and architecture, then six weeks of build, integration, and deployment. That hour count is lean on purpose. AI compresses the routine work, the CRUD, the scaffolding, the boilerplate, so engineering time goes to the parts that decide whether the thing is safe to ship: the auth architecture, the real-time witnessing, the audit trail, the integrations. Lean hours, not lean quality.
The headline work:
- Solved the auth deadlock with a 3-tier JWT system. Three token scopes (invite, partial, full) so registration could happen without an existing session, and onboarding could complete without granting full access too early. The 762-line auth route file was split into six focused modules: login, passkey, voice, invite, onboarding, and shared.
- Decomposed the monolithic pages into a reusable component architecture. Replaced 6 files of inline-everything with a service layer (testable business logic) and a component library (Tailwind v4: buttons, cards, inputs, sheet/drawer, tables, toasts, video player, stepper, file uploader).
- Replaced every stub with a real integration. AWS Connect Voice ID for voice biometrics (3-phrase enrollment, speaker verification). AWS SES for email (zero-PHI templates). AWS S3 (encrypted at rest, AES-256) for video recordings, voice samples, and certificates. PDFKit for DEA Form 41 generation with digital signatures.
- Built production infrastructure from scratch. Elastic Beanstalk for the Node.js + Socket.IO app. RDS PostgreSQL 16 (encrypted, automated backups). Application Load Balancer + ACM SSL (required for WebAuthn). Route 53 for DNS. CloudWatch for logging. Sentry for error tracking. GitHub Actions for CI/CD. Docker Compose for the dev environment.
- Designed the data model around the real workflow: 23 Prisma models across 4 domains (users/auth, waste management, training/onboarding, system/audit). 65+ REST endpoints with OpenAPI/Swagger documentation. Append-only audit log capturing every mutation with user identity, timestamp, action, entity, IP address.
Outcome: production-ready in 8 weeks from a state where no user could log in. 70% reduction in disposal time once deployed (remote witnessing eliminated the night-shift "find a second witness" problem). Monthly infrastructure cost runs $155-$531 depending on usage tier. DEA Form 41 generation, video evidence, biometric proof, and immutable audit trail all in place.
Where the Cost Actually Landed
The same project, by what was paid for and what showed up:
| Phase | What was bought | What was actually delivered |
|---|---|---|
| Original "MVP Complete" | A working MVP, ready for users | Source code with no users, no infrastructure, no real integrations, six months of founder time gone |
| Rescue rebuild (us) | ~120 engineering hours, 8 weeks, 2 AI-native devs | Production app: DEA Form 41 automation, biometric auth, video witnessing, audit trail, deployed on AWS, $155-531/mo to run |
The rebuild itself was the cheap part. About 120 hours of focused engineering, two AI-native developers, eight weeks.
What actually cost the founder was everything around it: the money already paid to the previous developer for code that never ran, the six months spent building a company on top of a prototype that looked finished and wasn't, and the customers and runway that slipped away while the app sat at "MVP Complete" doing nothing real. The rebuild is a line item. The lost time is the bill.
For contrast: the same shape of project, built right
Structured Settlement Platform — 5 weeks, $15K
A legal services startup needed an MVP fast: secure case intake, document upload, HIPAA-compliant storage, broker portal. Same scope as a vibecoded prototype. Compliance built in from day one rather than bolted on later. Five weeks. Production-ready. Client landed a $2,000/month retainer customer within weeks of launch.
Same shape of project. Different starting position. Different cost structure.
The Path Forward: Use the 80% as a Spec, Not a Codebase
The prototype's value is not the code. The prototype's value is the validated idea, the workflow proof, and the UI patterns your team already trusts. The code is usually 10-30% salvageable, mostly UI shells and component layouts. Authentication is rebuilt. The data layer is rebuilt. Access controls are rebuilt. The audit trail is built for the first time.
The realistic path:
- Audit the prototype (Week 1) — every screen, every workflow, every data flow. The prototype is your spec, not your codebase.
- Architecture and foundation (Weeks 2-3) — auth, RBAC, encryption, audit trails, database schema designed for the real data model. Shortcuts here compound.
- Rebuild features on the foundation (Weeks 4-7) — recreate the prototype's features on top of production architecture. Faster than expected, because the prototype already answered the hard product questions.
- Compliance verification (Weeks 8-9) — security testing, encryption verification, RBAC boundary testing, audit trail completeness, compliance documentation.
- Deploy and monitor (Week 10) — production deployment, monitoring, incident runbooks.
6-10 weeks with a team that's done it before. 4-6 months with a team learning compliance on the job.
Pricing
- Discovery sprint: $2,600, credited toward the build. Read the codebase, document the gaps, scope the rebuild.
- Compliance sprint: $4,400 over 2 weeks. Focused security and architecture review for projects where compliance is the constraint.
- Production builds in regulated industries: $44K-$107K depending on scope.
- Retainer maintenance post-launch: from $2,420/month.
- Minimum project size: $26K. Below this, coordination cost outweighs the saved scope.
If your prototype is hitting walls and you can feel the rebuild coming, the version of this conversation we'd rather have is the one that happens before you've spent another three months trying to prompt your way through it.
Related Reading
The two posts below cover industry-specific failure modes in detail:
- Your Vibecoded Healthcare App Isn't HIPAA Compliant (Here's What's Missing) — Lovable's PHI prohibition, the BAA chain, what HIPAA architecture actually requires, and the 3x cost difference between building compliance in vs. retrofitting it.
- From Vibecoded Prototype to Production-Ready Legal Tech — why lawyers are vibecoding their own tools, what breaks at the privilege layer, and the 6-10 week path to production.
Frequently Asked Questions
What does a rescue audit on a vibe-coded app actually find?
On the DEA Compliance Platform rescue, three days of audit on a "MVP Complete" handoff documented: an authentication circular dependency where passkey registration required auth and auth required a passkey, so no new user could register; six monolithic page files with the largest at 1,339 lines of inline HTML, logic, and state; 61 TypeScript errors with 8-10 critical (runtime crashes); missing service methods that prevented witness sessions from completing; zero production infrastructure (no hosting, database, storage, email, or CI/CD); and all external integrations were stubs returning hardcoded true values. We rebuilt it production-ready in about 120 engineering hours over 8 weeks.
Why does vibe coding only get to 80%?
The first 80% (UI layouts, basic CRUD, simple auth flows, navigation) has millions of training examples in public code. Pattern-matching at scale is the strength of LLM tools. The last 20% (production-grade auth, database-level access controls, audit trails, edge-case handling, compliance architecture, and infrastructure) requires architectural decisions specific to your data model and threat surface. Those are decisions, not patterns. AI tools generate code; they do not make architecture decisions.
Can I just keep prompting until the vibe-coded app works?
Almost never past the 15-20 component ceiling. Beyond that, the AI starts contradicting its own earlier decisions, breaking state management, and generating code that no longer compiles consistently. User-reported patterns include burning 400 credits per hour debugging, spending $1,000+ in tokens on auth that still doesn't work, and endless error loops. The failure mode is not solvable by more prompts.
How much of my vibe-coded app is salvageable when we rebuild?
Typically 10-30%, mostly UI shells and component layouts. Authentication, data access, access controls, audit trails, and compliance architecture are rebuilt from scratch. The prototype's real value is the validated workflow and UI patterns your team already trusts, not the code. The prototype becomes the spec document, not the codebase.
What does the rebuild cost?
Production builds in regulated industries run $44K-$107K depending on scope and compliance requirements. Discovery sprints to scope the rebuild are $2,600 credited toward the build. Compliance sprints (2 weeks of focused security and architecture review) are $4,400. Minimum project size is $26K. The rebuild itself is usually the lean part: the controlled-substance platform above took about 120 engineering hours. What costs a founder is rarely the rebuild, it is the months lost before it starts.
How long does it take to go from 80% prototype to production?
6-10 weeks with a team experienced in production systems and the relevant compliance. Week 1: audit and architecture. Weeks 2-3: foundation (auth, RBAC, encryption, audit trails). Weeks 4-7: feature rebuild on the proper foundation. Weeks 8-9: compliance verification. Week 10: deploy and monitor. Teams without regulated-industry experience typically take 4-6 months because they learn compliance requirements while building. The DEA Compliance Platform rescue took about 120 engineering hours over 8 weeks, with two AI-native developers.