Technical due diligence when the architecture diagram is 18 months old

Read the repository, not the diagram. The code, the Terraform and the CI configuration show what the system is today, including services no diagram mentions. Generate the architecture documentation from those, run the analysis inside the target's own environment, and spend interview time on the gaps between the picture and the story.

The diagram in the data room is often a PNG exported from a slide drawn for a fundraising round that closed eighteen months ago. It may still be right about the part that matters least.

What does a technical diligence actually need?

A technical diligence answers a few questions that move price or structure. It is not a code review.

Does it work the way the pitch says? The architecture behind the headline claims
Can it scale? What breaks at two or ten times the current load
Who can run it? How much of the system lives in one or two people's heads
What is it built on? Dependencies, licences, end-of-life components
What is the security posture? Secrets handling, access control, and whether the SOC 2 or ISO 27001 certificate describes the real system or a tidy version of it
What will it cost to fix? The number that goes into the model as remediation

Those questions need an accurate picture of the system first. A checklist applied to the wrong picture produces confident wrong answers, which is worse than none.

Why is the diagram always wrong?

Because a diagram is a hand-made copy of something that changes, and nobody owns the copy.

The system changes every week. A diagram changes when someone feels guilty. In a startup that is roughly never, and in a bigger company it is once a year before an audit. Add a period of heavy AI-assisted development and the gap widens, since code now arrives faster than anyone can redraw boxes.

The usual wrongness is specific and findable:

A service the diagram shows that was retired a year ago
Three services it does not show, usually the ones that handle money or customer data
A "single database" that is now five, including one nobody remembers creating
A queue between two components that was removed for latency, and a synchronous call quietly in its place
A third-party integration drawn as an arrow with no hint that it holds credentials

An out-of-date diagram is not evidence of bad faith. It is evidence of a company that shipped. The finding is the delta, and the delta only exists if you have a true picture to compare against.

What can you learn from the repository alone?

More than most people expect, and also less than the target's CTO will tell you in an hour.

From the repository you can establish with confidence:

Which services exist, how they are deployed and how they depend on each other
What the Terraform provisions, which is often a different list than what the diagram shows
What the data stores are, and which services read and write them
What the CI pipeline checks before something reaches production, and what it does not
Which third-party packages and APIs the system depends on
The change history: who touches what, how often, and which parts nobody has touched in two years
Where secrets are referenced, and whether they are referenced safely

That last pair is a lot of diligence for free. A module with one author and no commits for eighteen months is a key-person risk. A deploy path with no tests is a statement about change management more honest than a policy document.

What the repository will not tell you is whether the team can operate this under pressure, what the on-call experience really is, or what was said in the meeting where they chose the architecture. Generated documentation tells you what the system is. It does not replace the management interview, and it does not tell you if the people are good. It makes the interview a conversation about specifics rather than a guided tour.

How do you do this without the target handing over their code?

This is the objection that kills most code-analysis tooling in diligence, and it is the design constraint behind Zipper Blueprint for Engineering.

A target will not give an acquirer a clone of its monorepo. Ask a founder in a competitive process to ship the source to a counterparty who might walk away, and you will get a polite no from the founder and a flat no from their counsel. They are right. The code is the asset. Before signing, you are a stranger holding a copy of it.

So the analysis has to come to the code, not the code to the analysis. Zipper Blueprint runs inside the target's own AWS account, with repositories read in place instead of cloned out.

That changes the conversation. You are no longer asking the target to hand over the thing they value most. You are asking them to run a job and share the output, which their security team can read and approve. They can see what it generated before you do, and they can object to a specific line instead of the whole exercise.

One caveat. Some targets will refuse anyway. A refusal to let anyone look at the architecture, in any form, is its own entry in the red flags below. If you are evaluating tools in general, the security checklist lists the questions to put to any vendor, us included.

What are the red flags?

Things to write down and raise with management:

Infrastructure the diagram does not show. Not because it is wrong, but because unmapped infrastructure is where unreviewed access and unpaid cloud bills hide.
One person authors everything critical. The commit history makes this obvious. Key-person risk with a git blame attached.
No path to production that includes review. Direct pushes, manual deploys, credentials in config.
Certifications that do not match the system. A SOC 2 report scoped to the product from three years ago, with the current product running on a platform it never mentions.
Dependencies past end of life. Often small, occasionally a runtime that no longer gets security patches and holds the whole thing together.
A target who will not discuss the delta. The diagram being stale is normal. Defensiveness about why is not.

Rank them by what would change the deal: a price adjustment, a closing condition, a hundred day plan, or nothing.

Frequently asked

How long does technical diligence take with this approach? That has to be measured in a real pilot. The goal is to fit deployment, generation and human review inside a typical diligence window, but there is no production result yet that supports an hours estimate.

Does generated architecture documentation replace a code review? No. It tells you what the system is and how it is wired. A code review judges quality inside the boxes, and a diligence team that cares about one specific module still needs a person to read it.

Can the target edit the generated documentation before we see it? They should be able to correct factual errors, and you should ask to see the corrections. A fix that adds context is useful. A fix that quietly deletes an awkward service is a red flag, and the change history will show it.