Tech Due Diligence on Vibe-Coded Apps

"Vibe coding" — Andrej Karpathy's term, now a category — describes software built primarily by prompting an AI coding agent rather than by an engineer typing into an editor. Lovable, Cursor in agent mode, v0, Bolt, Replit Agent, Claude Code, Windsurf and a half-dozen others have collapsed the cost of shipping a working web app from weeks to an afternoon. A non-engineer can now stand up a Stripe-charging, Supabase-backed SaaS in a weekend.

That changes what's on the diligence table. We are now regularly asked to assess targets where the founder cannot read their own code, the entire backend was generated by an LLM, and the "engineering team" is one person and a Pro subscription. Some of these are real businesses with real revenue. Most are validated prototypes priced as systems. Telling the difference, quickly, is the new core skill of Tech DD on this asset class.

What counts as a vibe-coded app

Three signals, any two of which qualify the target:

1. More than ~60% of commits authored or co-authored by an AI agent. Inspect git history. Lovable, Cursor, Claude Code and most others either commit under a bot identity or leave consistent prompt-shaped commit messages.
2. Build-tool dependence. The app cannot be meaningfully extended without continuing to use the original AI tool — folder conventions, file naming, even the deployment pipeline assume the agent is still in the loop.
3. No engineer with end-to-end mental model. The founder describes features by user-flow rather than by data model; the technical answer to any question begins "let me ask the AI".

A target that hits all three is a vibe-coded app. A target that hits one is a normal company that uses AI tooling — diligence reverts to the standard SaaS playbook.

What's actually being acquired

Reframe before opening a single file. The asset is rarely the codebase. It is usually one of four things:

• Distribution. An audience, waitlist, or organic SEO position the founder built while shipping the product.
• Product-market fit signal. A working v1 that has reached paying customers fast enough to prove demand, regardless of the implementation quality.
• A datset or workflow. Customer data, prompts, fine-tunes, or an internal evaluation harness with genuine proprietary value.
• The founder. An operator who can use AI tooling to compress a normal engineering org down to one person — durable advantage in the right hands.

Buying the codebase as if it were the moat is the most common error. Price the actual asset; treat the code as something you may need to rewrite within twelve months and budget accordingly.

The vibe-coded app diligence framework

We run six workstreams. They overlap with classic Tech DD but the weighting and the specific questions differ sharply.

1. Provenance and reproducibility

Can the founder reconstruct why the system looks the way it does? Ask for:

• The original prompt log or chat history with the AI tool, ideally exported.
• The list of major refactors, with the prompt that drove each one.
• A written architecture summary the founder produced themselves (not generated). The quality of this document is the single best predictor of whether they understand their own system.

A founder who can produce all three is an order of magnitude lower risk than one who cannot. Provenance is the vibe-coded equivalent of a clean commit history.

2. Security: the standard three failure modes

Across 30+ vibe-coded targets we have reviewed, security defects cluster in the same three places. Test each, every time:

• Secrets in the client bundle. Pull the production JS bundle and grep for API keys, service-role tokens, webhook secrets, and provider keys. Anthropic, OpenAI, Stripe secret keys and Supabase service-role keys are the most common finds. Any one of these is a Repricing Event.
• Missing or permissive Row-Level Security. For any Supabase/Postgres-backed target, enumerate every table and confirm RLS is enabled with non-trivial policies. USING (true) is not a policy. Tables created mid-build that the agent forgot to lock down are routine.
• Public storage buckets. Inspect bucket ACLs. Default-public buckets containing customer uploads — invoices, IDs, contracts — appear in roughly one-in-three targets.

These are not exotic findings. They are the three things every AI agent has, at some point, gotten wrong. If the target's response to "how is your RLS configured?" is anything other than a precise answer, assume the worst and verify.

3. Schema and migration hygiene

Vibe-coded backends accrete schema. Look for:

• Duplicate tables with near-identical columns (users, profiles, accounts, user_profiles all containing email).
• Orphaned migrations that were rolled forward, edited, and re-run.
• Foreign keys to auth.users from tables the AI was told not to touch.
• text columns where jsonb, timestamptz, or enums should be.
• Indices on every column, or none.

A clean schema in a vibe-coded app is a strong positive signal — it means the founder has done at least one pass of cleanup with intent.

4. Dependency and bundle sprawl

Run npm ls --depth=0 and a bundle-size analysis. The pattern to look for:

• 40-80 dependencies, of which 10-20 are imported in exactly one file or not at all.
• Multiple libraries solving the same problem (date-fns and dayjs and moment; three icon packs; two HTTP clients).
• Heavy UI kits where the app uses three components.
• Dev dependencies in production.

This is fixable in a week, but it is diagnostic: it tells you the AI was asked for features without ever being asked to clean up after itself. Project that pattern forward to operations.

5. The runtime and operational picture

• Hosting. Is the app on a sensible platform (Vercel, Cloudflare, Fly, Supabase) or on the AI tool's default sandbox? The latter is fine for prototypes; for an acquisition it implies a forced migration.
• Domain, DNS, email. Who owns them? In a meaningful share of vibe-coded targets, the production domain is registered to the founder's personal Google account and the Resend/SendGrid sender is unverified.
• Observability. Any logs, error tracking, uptime monitoring? "We check the Vercel dashboard" is the modal answer and is not observability.
• Backups. Are database backups configured beyond the provider default? Have they ever been restored?
• CI/CD. Is there a deploy pipeline, or is "deploy" still a click in the AI tool's UI?

6. The human factor — can a real engineer take this over?

The most important question and the one buyers most often skip. Conduct one structured exercise:

Hand the codebase to an engineer who has never used the originating AI tool, give them four hours, and ask them to (a) write a one-page architecture summary, (b) make one non-trivial change, and (c) flag the three things they would refuse to ship to production.

Their write-up is the diligence finding. If a competent senior engineer cannot orient inside four hours, the target is not transferable and the buyer is acquiring a dependency on the original founder plus the original tool.

Red flags specific to vibe-coded targets

• A /admin route protected only by an unguessable URL. Common, and not authentication.
• JWT secret values hard-coded as fallbacks. process.env.JWT_SECRET || "dev-secret" in production.
• A single useEffect orchestrating the entire app's data fetching. Implies one prompt produced the whole frontend and no one has refactored since.
• Prompts embedded in the client bundle for LLM calls. The system prompt is your IP; if it ships to the browser, competitors have it.
• .env checked into git history. Run git log --all --full-history -- '*.env*' and grep for keys.
• Stripe in test mode handling production payments. Yes, we have seen it.
• No robots.txt, no sitemap, no meta tags. Indicates the founder never asked the AI for them, which indicates they never thought about distribution beyond paid acquisition.

Green flags

• A docs/ directory the founder wrote, not generated.
• A test suite — even a small one — that the founder can explain.
• Explicit type definitions for the database schema, regenerated on each migration.
• A working local dev environment that runs without the AI tool.
• One non-trivial integration (Stripe, Twilio, an embedding pipeline) that was not generated end-to-end and where the founder can explain every line.

Valuation framing

We typically discount vibe-coded targets along three axes against a comparable hand-built SaaS at the same ARR:

Axis	Typical discount	Recoverable post-close?
Code quality / rewrite risk	30-60%	Yes, in 3-9 months
Security posture	10-30%	Yes, in weeks
Bus-factor / key-person	20-40%	Only via earn-out or retention

The right structure is usually a lower headline price with an earn-out that keeps the founder building (and learning) for 12-24 months, plus an explicit budget line for a senior engineer hire within 90 days of close. Acquiring a vibe-coded company without a parallel hiring plan is acquiring an obligation.

How we run this on Lens

For Beyond M&A's own engagements we mirror the target's Supabase project read-only, snapshot the production bundle, and run a fixed evaluation harness: RLS coverage, secret-grep, dependency audit, schema lint, route enumeration, and a prompt-led code review. The harness produces the first 60% of the report in a working day, freeing the human time for the parts that actually require judgement — the founder interview, the architecture critique, and the transferability assessment.

If you are evaluating a vibe-coded target this quarter, this is the exact playbook we run. Book a working session and we will walk it against a redacted slice of the live data room.