Before a deal, an investor usually checks two things: finances and technology.
Lawyers go through incorporation documents, tax history, intellectual property.
But a product that makes decisions on its own (approves an application, screens a counterparty, calculates a payout) has a third layer.
People often forget about it: the legal logic of the algorithm itself.
Three Layers of Due Diligence, and Why One Gets Skipped
Due diligence on a startup (a check on the business before a deal) usually comes down to three questions.
- Are the finances in order?
- Is ownership of the business cleanly documented?
- Does the technology do what it claims?
Accountants and lawyers cover the financial and legal layers.
The technical layer is usually covered by the investor’s own IT lead (CTO) or a hired developer.
The question of whether the logic the code actually runs was designed correctly goes unanswered.
An accountant’s focus is the numbers: balance sheet, taxes, expenses.
A developer’s focus is the code: does it run without technical bugs.
Whether the logic itself is lawful simply falls outside anyone’s view.
A general-practice lawyer’s focus is contracts and internal paperwork.
Who actually makes the decisions inside the algorithm stays a mystery.
One caveat right away: in regulated verticals like banking, insurance, and healthcare, dedicated compliance lawyers already ask for a description of the algorithms as part of industry-specific due diligence.
For them, this is nothing new.
The real gap is different: this kind of review usually happens once, verbally, with no single document anyone can return to at the next funding round or after a team change.
The blind spot exists because there’s no system for it: outside these narrow verticals, this kind of check happens sporadically, if at all.
In some places it simply doesn’t happen at all.
What Gets Missed in the Review
Formalities like licenses and liability disclaimers in the terms of service matter too.
That’s a general-practice lawyer’s territory.
What comes next is different: specific decisions inside the code.
- In which cases does the algorithm approve a request on its own?
- When must it stop and hand the decision to a person?
- Where is that line, and who drew it?
More often than not, that line gets set by whatever was easiest for the developer to code at the time.
The product can run for months without a single complaint.
Then one rare case turns into a fine, a lawsuit, or a damaged reputation.
And by then, the investor’s money is already in.
One common example of that kind of line: how a product tells an outside service’s technical failure apart from a genuine legal refusal. See it worked through on a real example →
What About a Neural Network?
Good question.
With code, the rules are visible: “if — then.”
A neural network has none of that: it’s trained on examples and finds patterns on its own.
An audit doesn’t try to read a model’s weights.
That’s millions of numbers no human can meaningfully read, and none of that matters for the review anyway.
It looks at what’s built around the model:
- Is there a confidence threshold below which the system must stop and hand off to a person?
- Is every decision logged so it can be reviewed later?
- What happens when the model’s own confidence in its answer drops?
That’s what actually draws the line between automation and human accountability, not the model’s internals.
What Needs Attention Now, and What Can Wait
There’s a real line here.
Think regulated verticals: lending and credit scoring, insurance, healthcare, hiring (HR-tech), compliance automation (RegTech), and other spaces where decisions touch people’s rights.
There, the cost of a mistake goes far beyond a single fine.
A license, a reputation, and an executive’s personal liability can all be on the line.
An ordinary consumer product at the earliest stage (an MVP) is a different story.
If the algorithm is only making simple calls with no legal consequences yet, a deep audit of the logic can comfortably wait for the next round.
That’s fine, but it’s worth coming back to.
How This Gets Handled in Practice
There’s a dedicated format for this layer: Audit & Second Opinion.
It’s a fast review focused specifically on the legal logic.
A specialist looks for two kinds of spots:
- where the algorithm could give a user a dangerous or legally unsound answer;
- where it should have stopped, but kept running instead.
You get back a report with concrete risk points:
- what could go wrong;
- under which scenario;
- how to fix it.
The audit surfaces systemic logic gaps and legal risks within the scenarios reviewed, and helps you close them before the deal.
It has limits, though: it doesn’t replace operational compliance, and it isn’t insurance against every future lawsuit.
Some startups simply don’t have legal logic yet, and then the question shifts to designing it.
There’s a separate format for that: Core Architecture & Triage Logic.
Checklist: What to Ask a Startup Before Due Diligence
- Who made the calls in the grey areas of the logic? If the answer is “the developers just decided as they went,” that’s a sign no one designed the legal layer on purpose.
- Is there a document describing where the algorithm must stop? This means a plain-language description: which cases get handed to a person.
- Has anyone besides the team itself reviewed this logic? A team’s own confidence in its product is no substitute for an independent check.
There may not be such a document, and that’s fine: plenty of fast-growing companies don’t have one either.
That’s worth asking about: how the team plans to create it.
Due Diligence Inside a Company
Due diligence isn’t only for an investor before they put money in.
It’s just as necessary for someone taking over a company from the inside — a new CEO or commercial director stepping into a role at a business that’s already running.
The principle is the same: check before you take on the responsibility.
Only the direction changes: instead of looking outward at someone else’s startup before a deal, it’s now pointed inward, at your own new area of responsibility inside the company.
Checklists for that situation live in two guides: “Taking Over as Director” and “Taking Over as Commercial Director” (Russian only, for founders working with Russian-market companies).
Frequently Asked Questions
How is due diligence on legal logic different from a regular legal review? A regular legal review, as part of due diligence, looks at contracts, corporate structure, intellectual property.
A review of the legal logic looks at something else: what the algorithm itself actually does, and whether that violates the law or a user’s rights.
Who usually starts this kind of review: the investor or the founder? Both sides do.
An investor wants to understand the real risks before investing.
For a founder, it means walking into negotiations with independent confirmation in hand instead of promises.
Isn’t it simpler to just budget for future fines than spend time reviewing the logic? For an unregulated consumer product at a very early stage, there’s a real logic to that: the cost of a mistake is genuinely limited and predictable there.
For a regulated vertical, it’s a risky bet.
A fine there is usually just one part of the cost, on top of license revocation, regulatory orders, and reputational damage that never makes it into anyone’s budget in advance.
How long does this kind of review take? Of the four legal-architecture formats, Audit & Second Opinion is the fastest, precisely because it works with logic that already exists instead of designing it from scratch.
Want to know what’s actually being checked in your product’s legal logic before a deal?
See how the audit works: Audit & Second Opinion among the other ways to work together.