You spent a weekend in Cursor or Lovable and shipped a working MVP. The vibe was good, the dopamine was real, and your early users were impressed. Now you're trying to add features, onboard a developer, or pass a security review, and the code that felt magical a month ago feels like quicksand.
Vibe-coded MVPs become technical debt the way startup codebases always have: too fast, too unstructured, with nobody reviewing the output. Here are ten signs your AI-built MVP has crossed into debt territory, ranked from least to most urgent.
1. You have files over 1,000 lines
AI tools generate code, but rarely refactor it. The output keeps accreting until a single React component is doing the work of fifteen. Run wc -l on your source files. If more than five are over 800 lines, your codebase has been growing without decomposition.
Cost to fix: a 2-week cleanup sprint for the worst offenders. Files under 300 lines are easier to test, refactor, and understand.
2. Your test coverage is zero
Run your test command with coverage. If the number is 0% (common) or under 10% (very common), every change you make has a meaningful chance of breaking something else.
Cost to fix: add smoke tests for the most important user flows first. Unit tests for critical business logic come second. Aim for 60-80% coverage on the modules that matter, not 100% everywhere.
3. TypeScript is mostly "any"
Turn on strict mode in tsconfig.json and run tsc --noEmit. Count the errors. Under 50: manageable. Over 500: the AI has been generating without type safety, and every change risks runtime errors that TypeScript should have caught.
Cost to fix: incremental, enable strict mode file by file, not all at once.
4. You can't run the app locally
If your local dev story is broken, or the app only runs inside Lovable / Replit / Bolt, you don't actually own your software. Try this: clone your repo into a fresh directory and follow your own README. If you can't get it running in 15 minutes, neither can the next developer you hire.
Cost to fix: a few days to set up Docker Compose or proper npm scripts.
5. Secrets are committed to git
Run git log --all -p | grep -iE "(api_key|secret|password|token).*=". If anything comes back, you have credentials in your git history. They're not just exposed now, they're exposed forever, even if you remove them from HEAD.
Cost to fix: immediate. Rotate every exposed secret. Use BFG or git-filter-repo to scrub history if the keys can't be rotated cheaply.
6. Your Supabase RLS is permissive
Open your Supabase dashboard, go to Authentication → Policies, and check every table holding user data. If you see USING (true) for the anon role on any of those tables, anyone with your URL can read that data. AI tools generate this policy by default to make the demo "work".
Cost to fix: hours, but high urgency. Tighten policies to row-owner only.
7. Every AI change breaks a different feature
If you've noticed that asking the AI to change one thing keeps breaking something unrelated, that's a sign your code has hidden coupling. Functions are tangled together, modules share state implicitly, and the AI doesn't see the dependencies until they break.
Cost to fix: targeted refactoring of the most-changed files. Add tests first so regressions show up immediately.
8. You're locked into a platform
Lovable's templates, Replit's runtime, v0's component patterns, Bolt's full-stack scaffolding, each one creates lock-in. The question to ask: can you move this app to Cloudflare Pages or Vercel today, without rewriting more than 20% of it? If no, you have vendor lock-in.
Cost to fix: ranges from a 2-week migration to a full rewrite, depending on how deep the platform integration goes.
9. New developers take weeks to ramp up
Hand the repo to a developer who didn't build it. Ask them to add a small feature. If it takes longer than two hours, your code is harder to read than it should be. That cost compounds with every new hire.
Cost to fix: documentation, file decomposition, and consistent patterns. A few days of investment to save weeks per developer.
10. You're afraid to deploy
The clearest sign of technical debt is fear. If pushing to production feels risky, if you delay deploys, if every release requires manual testing, if you've considered freezing development to avoid breaking things, your code is telling you something. Listen to it.
Cost to fix: CI/CD pipeline with automated tests, staging environment, and a rollback plan. This single change reduces deploy anxiety more than any other intervention.
What to do next
Three or fewer signs apply: add CI/CD and basic tests yourself. You're fine. Four to six signs apply: book a code audit and plan a stabilization sprint. Seven or more apply: stop adding features until you've addressed the foundation, every new feature on top of broken foundations multiplies your future cost.
See our Vibe Code Rescue service for audit and refactoring help. Or read the pillar guide: What Is Vibe Coding and When Does Your AI-Generated App Need Rescue?