The Future of Tech DD: Investing in a Vibe-Coded World

Tech DD as practised today is a product of the 2010s. It assumes a target with a small engineering team, a Git history that reflects human decisions, a codebase that can be read top-to-bottom in a week, and a security posture that is mostly a function of how disciplined that team was. The questions on the checklist — language choice, test coverage, CI maturity, on-call rotation — all presuppose that humans wrote the software and humans maintain it.

That world is ending faster than most investment committees realise. The interesting question is not whether vibe coding is "real engineering" (an argument that has already been lost on both sides) but what Tech DD looks like when half the deal flow is software that no human fully authored.

Why this matters for investors, not just engineers

There are three structural shifts happening at once, and they compound:

1. Cost of shipping has collapsed. A solo founder with a Lovable or Cursor subscription can now produce, in a weekend, what required a seed-funded team of four in 2021. This means more targets, faster, at smaller cheque sizes — and a long tail of "businesses" that are really validated prototypes wearing SaaS clothing.
2. Quality variance has exploded. The best AI-assisted teams are shipping faster and with fewer defects than their 2022 selves. The worst are shipping production systems with credentials in the client bundle and no Row-Level Security. The gap between P10 and P90 quality in any given vintage is now wider than at any point in the last twenty years.
3. The traditional shops are converging downward — or upward, depending on your view. By 2026 it will be vanishingly rare to find a 50-person engineering team that isn't using Copilot, Cursor, or Claude Code for the majority of net-new code. The line between "vibe-coded startup" and "real engineering org" blurs every quarter. Diligence frameworks that depend on that distinction will stop working.

The investor takeaway: you cannot reliably price these assets with a 2019 Tech DD template. You will either reject good deals because the codebase "looks AI-generated" or, more dangerously, pay SaaS multiples for what is really a UI on top of someone else's infrastructure.

What Tech DD looks like in 2027

Our working forecast — informed by the 80+ targets we have assessed in the last 18 months where AI tooling was material — is that the diligence stack reorganises around four questions, in this order:

1. Data lineage — the new code review

Where does customer data physically sit? Which third parties (LLM providers, vector DB hosts, observability vendors, AI builder platforms) have processed it, and under what terms? Can the target produce a data flow diagram that matches reality?

This becomes the single highest-leverage workstream because it is the area where vibe-coded targets are most likely to have created liabilities they don't know exist. A founder who prompted "add Stripe checkout" may not realise the AI agent also wired up an analytics SDK that pipes every page view, including PII in URL params, to a US-based vendor whose DPA they never signed.

2. Provenance and intelligibility

Not "is the code clean?" but "can a new engineer load the system into their head in a week?" The artefacts that matter: the prompt log (or its absence), the architectural decision record, the migration history, the deployment runbook. A 50,000-line codebase that a competent mid-level engineer can fully grasp in five days is more valuable than a 10,000-line codebase that requires the founder's continual interpretation.

3. Operator dependency and the human factor

This replaces "key-person risk" as the dominant people question. The framing shifts from "what happens if the CTO leaves?" to "is there anyone in the organisation who can debug a production incident at 2am without re-prompting the AI?" Many vibe-coded targets answer no. That is not automatically disqualifying, but it has to be priced.

4. Defensibility of the system, not the code

In a world where any competitor can re-generate functionally equivalent code in a weekend, what makes this product defensible? Data network effects, distribution, brand, regulatory moats, integration depth — none of which appear on a code-quality scorecard. Tech DD has to start asking commercial questions it has historically left to commercial DD.

The classic workstreams — security, scalability, IP, open-source compliance — do not go away. They become table stakes, the floor not the ceiling.

What founders are getting wrong about vibe coding

We see the same three misconceptions repeatedly, and each one creates a specific diligence finding that lands in our reports.

Misconception 1: "The AI doesn't keep my code or data"

Most AI builder platforms have a free tier or hobbyist plan whose terms of service explicitly reserve the right to train on, retain, or analyse user inputs and outputs. The paid tiers usually carve this out — but the carve-out is conditional on which features are enabled (preview sharing, public projects, telemetry), and founders routinely sign up on the free plan, ship a real product on it, and only upgrade after the data has already been ingested.

The diligence question is not "do you use Lovable / Cursor / v0?" It is "which plan, since when, and what was your project's visibility setting before the upgrade?"

Misconception 2: "My secrets are safe because they're in environment variables"

This is the single most common Sev-1 finding on vibe-coded targets. The founder believes secrets are server-side because the AI agent said it put them in the .env file. In reality, any variable prefixed VITE_, NEXT_PUBLIC_, or REACT_APP_ is shipped to every visitor's browser. We routinely find Stripe live keys, OpenAI API keys, Supabase service-role keys, SendGrid keys, and admin webhook secrets in the public JavaScript bundle of targets pitching at 6–8x ARR.

The AI didn't lie — it put the variable where the founder asked. The founder didn't know which prefix means "public". Nobody reviewed it. The first time anyone checks is during diligence, and by then those keys have been live and indexable on the public internet for months.

Misconception 3: "My data is in my database, which is mine"

Most vibe-coded apps sit on a managed BaaS — Supabase, Firebase, Neon, PlanetScale, or a hosted Postgres. The customer relationship, the SLA, the data residency, the backup retention, and the ability to actually export the data in a portable form all depend on the BaaS terms, not on the founder's intuition that "it's my database."

Three sub-issues we flag repeatedly:

• No RLS, or RLS only on the tables the founder remembered. The default posture of a fresh Supabase project is that with the anon key, every row in every table is readable. Vibe-coded apps inherit this. We have seen targets where competitors could enumerate the entire customer list with a single curl request.
• No data residency guarantee. A UK-based target selling into UK SMEs may be storing all customer data in us-east-1 because that's the default region the AI selected. Under UK GDPR, that is a disclosable international transfer with specific obligations the founder has not met.
• No real backup strategy. The BaaS does point-in-time recovery for 7 days on the plan they're on. The founder believes this means "my data is backed up." It does not mean they can restore to a position from three months ago when a bad migration corrupted a table.

Where the data actually goes

For an investor reading a vibe-coded target's data flow, the honest answer to "where is my data?" is usually some combination of the following, none of which appear on the pitch deck:

• The application database — typically a managed Postgres at a US or EU hyperscaler, owned by the BaaS vendor, governed by their DPA.
• The AI builder platform's project storage — every prompt the founder ever wrote, plus snapshots of generated code, retained per the builder's plan terms.
• The LLM provider behind the builder — OpenAI, Anthropic, Google, or a mix, each with their own retention windows (typically 30 days for API traffic on enterprise plans, longer or indefinite on free/consumer tiers).
• Embedded analytics and error tracking — PostHog, Sentry, LogRocket, Vercel Analytics, or whichever the AI inserted by default, each with their own data residency and PII handling.
• The deployment platform's edge logs — Vercel, Cloudflare, Netlify all log request metadata, often including URL parameters and headers that contain user data.
• The payment processor — Stripe or similar, governed by their own terms, usually fine but rarely mentioned in the target's privacy policy.
• Any "AI features" inside the product itself — if the app calls OpenAI to summarise a customer document, that document just left the perimeter. The founder may not have a DPA in place to make that legal.

Six to eight data processors, on average, for an app the founder describes as "self-hosted on our own Postgres." None of this is uniquely bad — traditional SaaS has the same surface area — but it has to be enumerated, mapped, and contractually papered. Most vibe-coded targets cannot produce that map on day one of diligence.

How the investor playbook changes

A few practical shifts we are already making in our own engagements, which we expect to become standard across the industry in the next 24 months:

• Earlier security touch. Pre-LOI, not post-LOI. A 90-minute scan of the client bundle and the public BaaS endpoints catches the deal-breaking issues before either side has spent legal fees.
• Data-flow mapping as a deliverable in its own right. Not buried in the security appendix — a standalone artefact the buyer's DPO can use directly.
• Rebuild-cost as a valuation anchor. For sub-£5m targets, the question "what would it cost to rebuild this from the spec in 8 weeks?" is now a meaningful valuation floor. If the answer is "£150k", then £2m of goodwill needs to be justified by distribution, data, or contracts — not code.
• A maintainer covenant. Post-close, the seller commits to a 90-day window in which a buyer-nominated engineer can shadow them and document the system. This costs the seller little and de-risks the buyer substantially.
• Explicit AI-tooling reps and warranties. Standard SPAs do not yet have language covering "no confidential customer data was processed by an AI service without a DPA." They will within 18 months. Early movers are already adding it.

The bigger picture

Vibe coding is not a fad and it is not the end of software engineering. It is the largest shift in how production software gets built since the move from on-prem to cloud, and it is happening on a timescale of quarters rather than years. The Tech DD that worked in 2019 will produce systematically wrong answers about 2027 targets — sometimes too conservative, sometimes catastrophically too permissive.

The opportunity for investors who get ahead of this is significant. Two-thirds of the targets we see flagged as "low quality, AI-generated, pass" are actually well-positioned businesses with cheap, fixable hygiene issues. A smaller but non-trivial fraction of the ones flagged as "clean, traditional, proceed" are sitting on undisclosed data-processing liabilities that would not survive a serious DPA audit. The diligence framework that distinguishes between them is the edge.

It is not a code-quality question any more. It is a systems, data, and operator question. Tech DD is becoming what it probably should have been all along.

Where to start

If you are an investor with a live deal where the target was built primarily with AI tooling, the companion piece — Tech Due Diligence on Vibe-Coded Apps — is the operational checklist. This article is the thesis; that one is the playbook.

If you are a founder reading this because you built the product yourself and now have a term sheet, the single most useful thing you can do before diligence starts is open your deployed JavaScript bundle in a browser, search it for the strings sk_live, service_role, SUPABASE_SERVICE, and OPENAI_API_KEY, and address whatever you find. That one check, before a buyer's engineer runs it, is worth more than any pitch-deck revision.