Due diligence for vibe coded startups: What to check before you invest

A year ago, the fact that 30% of internal codebases were AI-written (Microsoft and Google included) made investors ask where the IP was. Now, it makes them wonder why the team is slow.

What changed?

Arguably, whether AI-generated code can turn into a lasting business.

Due diligence for vibe coded startups checks whether an AI-built product is owned, understood, secure, defensible, and fit to scale, and what it will cost to get there. The percentage of AI-generated code takes a backseat to the team's ability to maintain it and the company's ability to defend its position.

The percentage of AI-generated code is a poor shortcut. Everybody can prompt. A codebase written largely by AI can be a sound investment only if the team understands it and the product has a durable advantage.

What “vibe coded” means when you're the investor

Just so I cover all the bases, the term ‘vibe coding’ describes software development driven by natural language prompts to AI models, sometimes with limited attention to the underlying implementation.

It covers a broad spectrum, from experienced engineers using AI assistants to non-technical founders generating entire applications. Both approaches can produce useful software, with the difference in how much engineering judgement remains with the team.

As a result, faster and cheaper development changes the economics of building a company. Perhaps more importantly, it changes what deserves scrutiny. Since a small team can reproduce a product quickly, the goal is to gauge what makes this particular company difficult to copy.

Which brings us to:

Why a demo and a founder call no longer tell you enough

A polished demo rarely shows what happens when a payment fails, permissions change, an integration goes offline, or any other unexpected scenario. Then, there’s AI and its capacity to generate architecture and business logic that the founder struggles to explain independently.

Interviews and samples of selected files can miss these weaknesses. A repository review provides a broader view of change history, dependencies, tests, configuration, and how the application works.

Automated analysis can examine the codebase, while experienced operators verify findings that could affect the investment. The grand idea here is to establish which risks could change the valuation and funding needs, or even the decision to proceed.

Seven checks for AI-generated code due diligence

1. Defensibility: Could someone rebuild it in a week?

We all know that AI has lowered the cost of reproducing countless software features. It has also lowered the creation entry barrier, so to speak, in a way that another team can relatively easily recreate the same thing using the same models and tools.

You’d think that would make a business worthless, but it doesn’t.

Its advantage may lie in any number of things, like proprietary data, customer relationships, specialised workflows, distribution, or accumulated knowledge about a particular market, to name a few.

• Which capabilities depend on proprietary technology and not on the standard model APIs and readily available components?
• Does the company have legitimate access to unique data, and does using that data create a lasting advantage?
• Are customers paying for a differentiated outcome or for a convenient interface around an existing model?

2. Ownership: Does the company own what it's selling?

A product can run flawlessly while ownership remains unclear. It’s because AI coding tools, freelance devs, open-source elements, and no-code platforms introduce different contractual and licensing questions.

The relevant terms depend on the tool and its applicable agreement, together with the circumstances in which the code was created. All that is to say, the rights to the AI-generated code need to be established before automatically treating it as either company-owned or unusable.

• Applicable terms for AI coding tools and external services used to build the product.
• IP assignment agreements covering founders, employees, contractors, and anyone else involved.
• Open-source licences and any restrictions relevant to commercial use or distribution.
• Whether the code can be exported, independently deployed, and maintained without a proprietary builder platform.

3. Control: Does the team understand what it built?

AI can generate a working implementation and leave the founder without a clear mental model of its architecture. The resulting disparity becomes expensive when the product needs an urgent fix or a substantial change.

The test is whether the team can maintain the software.

• Can an engineer other than the original builder explain the important elements and data flows?
• Can the team deploy the application, investigate an incident, and modify core business logic?
• Are architectural decisions and operational procedures documented beyond the original prompt history?
• Is responsibility concentrated in one person, creating a high bus factor risk?

4. Security: Does the product withstand real attacks?

Unfortunately, AI-generated code can contain the same vulnerabilities found in human-written software, as one user study found. The problem is especially concerning when inexperienced builders accept generated code without understanding its security implications.

What’s more, researchers also found that AI-assisted participants were more likely to believe their code was secure. If anything, the data reinforces the need for independent verification.

• Hard-coded API keys, exposed credentials, and unsafe configuration.
• Authentication, authorization, and input validation on important application flows.
• Vulnerable dependencies and unsecured endpoints, along with potentially unsafe handling of customer data.
• Whether security testing covers realistic attack scenarios or only expected user behaviour.

5. Scale: Can the product support the growth you're pricing in?

In another similar situation to understanding what’s been built, an MVP can work well with a handful of users but struggle when usage increases. Once again, AI-generated implementations are the culprit due to everything from inefficient database queries to infrastructure choices that become expensive as demand grows.

Simply put, investors need a credible account of the work required to support the growth assumptions in the financial model.

• What happens to performance and infrastructure expenses if customer numbers increase tenfold?
• Are database design, background jobs, integrations, and failure recovery appropriate for the expected workload?
• Which parts of the system would need reworking before entering a larger market or serving enterprise customers?

6. Delivery: Is the team making progress or accumulating code?

Since changes come quickly with AI coding tools, things like feature lists and shipping frequency become less reliable as indicators of engineering performance.

The useful measure is whether the team can make changes safely and repeatedly. A growing codebase with weak tests and little review may create more work than it removes.

• Do automated tests run successfully, and do they cover the product's important user journeys?
• Are changes reviewed and tested before deployment?
• Does the team track regressions, failed deployments, recurring defects, and related processes?
• Can engineers explain the relationship between recent changes and the product's behaviour?

7. Cost: What happens when the credits run out?

Vibe coding can reduce initial development spending by replacing some engineering hours with AI tools. The problem is that expenses move elsewhere, often beyond view.

For example, inference costs may grow with product usage. AI services can change their pricing, and the company may need monitoring tools or experienced engineers to maintain the application. Just like that, a product that was cheap to prototype can become expensive to operate.

• Cost of model calls and external AI services under realistic usage assumptions.
• Dependence on one vendor and its pricing.
• Availability of alternative providers.
• Engineering budget required for both current development (maintenance, security) and future development.
• Whether the company has modelled the cost of replacing platform-specific components or rebuilding weak areas.

The investor's checklist at a glance

Green flags: What a well-built AI-native company looks like

By all means, founders should be able to explain where AI accelerated development and human review is needed, along with which limitations they have accepted.

Look for evidence of a working engineering process:

• Changes to important business logic receive human review.
• Tests cover the customer journeys where failures would hurt most.
• Architectural decisions and operational procedures are documented.
• The company has a clear view of external dependencies and their costs.
• Its competitive advantage comes from something more durable than the ability to generate code.

The strongest signal is a team that treats AI as a development tool while retaining responsibility for the resulting product. That approach leaves room for technical debt without making the business dependent on luck.

What the due diligence for vibe coded startups means for the deal

Technical due diligence should inform decisions besides coming up with a list of defects. Some findings affect valuation; others require conditions before closing. Less urgent work can become a funded 100-day plan with named owners and deadlines.

The decision is rarely as simple as investing in a perfect codebase or rejecting an imperfect one.

Hence, the issue is whether the risks are understood and consistent with the return the fund expects.

If the team can’t explain the product, ownership is undetermined, the financial model excludes the cost of making it production-ready, or there is some other uncertainty, problems will compound. A cheap initial build offers little comfort if the investor must later finance the engineering work needed to make the product viable.

Why technical due diligence belongs before the term sheet

Once a price has been agreed, investors may be reluctant to reopen negotiations. Reviewing the technology earlier gives them room to price risks and agree on remediation or walk away.

How X-Ray checks a vibe-coded codebase

X-Ray runs more than 250 automated checks and delivers two reports in one business day: an investment-focused assessment for the deal team and a technical report outlining findings and next steps for the company. The process requires read-only repository access and approximately 30 minutes of the target company's time.

Here’s what Wouter Goossens, Partner at Fortino Capital had to say about X-Ray:

In terms of AI-built products, this approach helps investors investigate whether the company owns and understands what it sells, and has a credible plan for future development.

In doing so, X-Ray gives investors evidence they can use before setting terms, while there’s still room to price risk, agree on remediation, or walk away.

Frequently asked questions

Is vibe coding a red flag for investors?

Not necessarily. AI-assisted development can help small teams build useful products. The concern is whether the founders can maintain and secure the software, and whether the business has a defensible advantage. Assess the technology and economics before rejecting a company based on how its code was produced.

How do you tell if a startup's product was vibe coded?

Review the repository's history, code structure, changes, and tests, then compare the evidence with the founder's explanation. These clues can suggest extensive AI-assisted development, but no single pattern proves how the code was written.

Who owns AI-generated code?

Ownership depends on the AI tool's terms, incorporated code, and agreements with founders, employees, contractors, and any other parties. Investors should have legal counsel review relevant terms, IP assignments, and licences, and avoid assuming the startup automatically owns all generated code.

Does the EU AI Act apply to vibe coded products?

By itself, using AI to write software doesn’t bring a product under the EU AI Act. Applicability depends on the product and the role of any AI system it contains, including its intended purpose and risk category. Legal advice may be needed.

How long does technical due diligence take?

Traditional reviews can take several weeks, depending on the company's complexity and scope. Scaleflow says X-Ray delivers its two reports (investor summary and full technical report) in one business day. Further investigation may take longer if access or evidence is incomplete or significant issues emerge.

Can a vibe coded product scale?

Yes, provided its architecture, security, and operations suit its intended use. Some products need incremental improvements, while others require substantial rework. Investors should establish what engineering is needed and when it must happen, then determine whether the funding plan covers the cost.