What technology problems actually reprice a deal?

Found in diligence means priced, not fixed

Most technology findings don't change the price. They go on a list, get an owner, and become someone's problem after close. A handful behave differently — they change what a buyer is willing to pay, or how the deal is structured.

The difference isn't severity. It's whether the problem creates uncertainty a buyer can't quantify before signing.

Timing does most of the work. By the time a buyer's technical team is in the codebase, you're usually under an LOI, inside exclusivity, working toward a signing date. Fixing a real technology problem — documenting a system only one person understands, replacing a copyleft-licensed dependency, scoping regulatory obligations properly — takes months. The deal doesn't have months.

So the finding doesn't get resolved. It gets allocated: an escrow holdback, an indemnity carve-out, a rep you have to stand behind, an exclusion in the R&W insurance policy, or a lower number.

1. Knowledge that lives in one person's head

This is the one that shows up most, and it usually isn't the founder. It's the founding CPO or an early engineer — someone who holds years of undocumented product decisions and knows why the system works the way it does.

That person is often not the one receiving the largest share of the consideration, which makes their post-close commitment genuinely uncertain. A buyer will notice.

The clearest version of this I've seen wasn't in a document. A target's head of IT mentioned, almost in passing, that he couldn't take a vacation. He was the only person who could run the environment. That one sentence told me more than the backup documentation did — because backups nobody else can restore aren't really backups, and there was nobody behind him. The recommendation wasn't technical. It was to hire his replacement now, so the company wouldn't be blindsided the day he won the lottery.

The response from a buyer is structural rather than technical: retention packages, earnouts tied to named individuals, extended transition services. All of which change deal economics, and often move consideration away from where the sellers expected it.

What reduces it isn't documentation for its own sake. It's whether a second person can operate the system, and whether the reasoning behind key product decisions exists anywhere outside one head.

2. Copyleft exposure in your product

GPL and AGPL-licensed components carry obligations. If they've been linked into proprietary code you distribute — or under AGPL, code you serve over a network — the licence may require you to make source available.

Most companies with this problem don't know they have it. A developer pulled in a library that solved a problem, nobody reviewed the licence, and it's now several layers deep in a dependency tree.

This one goes pre-close on discovery for a specific reason: the remedy isn't a policy or a process. It's re-engineering, a commercial licence, or an unresolved legal question about what a competitor could demand. That's the shape of risk a buyer won't carry unpriced.

3. Regulatory scope you haven't identified

Not "you're out of compliance." Worse — you don't know which rules apply to you.

A company processing card data that has never scoped itself for PCI DSS. A company touching health information that hasn't asked whether it's a business associate under HIPAA. A company with EU customers and no clear view of its GDPR obligations.

A known gap is a remediation project with a cost and a timeline, and buyers price that easily. An unknown scope is unbounded, and unbounded is where valuations get discounted hard. The buyer isn't pricing the fix — they're pricing the range of things they can't see.

"We looked and concluded X" is a defensible position. "We never looked" is not.

4. AI features you can't establish rights to

This one is newer and increasingly common.

If your product includes AI capabilities, a buyer will ask what data trains or grounds them, and whether you had the right to use it that way. Customer data used for model training without contractual permission is a live problem. So is uncertainty about who owns AI-generated code in your codebase, and dependence on a single model provider with no fallback.

The diligence question isn't whether you use AI. It's whether you can demonstrate you're entitled to use it the way you do, and whether that entitlement survives the customer relationships changing hands.

What usually doesn't move the price

Worth saying plainly, because founders spend anxiety in the wrong places.

• Technical debt. Every company has it and buyers expect it. Debt that's tracked and deliberately managed reads as maturity. Undisclosed debt is a trust problem — but the debt itself is normal.
• Unfashionable architecture. A monolith is not a finding. A monolith nobody can deploy safely is a finding. Buyers care whether the system supports the growth in their model, not whether it matches current fashion.
• An imperfect security programme. Gaps at a small company are expected and priced as remediation. What isn't priced casually is an undisclosed incident, or a gap in an area you're regulated for.
• A small team. Buyers acquiring a small company know they're acquiring a small team. What matters is whether the knowledge transfers.

What to do about it

The useful question isn't "is our technology good." It's what will a buyer find, and which of those things will they want resolved before they sign.

Those are different lists. The second one is short, and every item on it takes months to fix — which is why the only time to work on it is before you're in a process.

• Make the critical systems operable by more than one person, and write down why the key product decisions were made the way they were.
• Inventory your dependencies and their licences. You're looking specifically for copyleft in anything you distribute or serve.
• Scope your regulatory obligations. Not compliance — scope. Write down which regimes apply and why.
• If you have AI features, document what data grounds them and what gives you the right to use it.