Read from the running system, not from a repository or a deck. The difference between recorded state and deployed state is where most surprises live.
KeevaathTech/Services/Technical due diligence
LENS · Product assessment
Technical due diligence
An independent read on what you would be buying or funding, written for the person making the decision and opening with the conclusion.
What this is
An independent read on the technology of a company you are considering buying, funding or partnering with. What was actually built, what state it is in, what it would cost to keep running, and which of the risks are the kind that change a price.
Written for the person making the decision, which means it opens with the conclusion and puts the evidence behind it.
The question this answers
Not whether the code is elegant. Whether the thing you are paying for exists, works, can be maintained by somebody other than the people who wrote it, and carries no liability nobody mentioned.
Four findings recur often enough to be worth naming. A product that depends entirely on one person who is not part of the deal. A dependency stack so far behind that the first year post close is consumed by upgrades. Licensing that was never examined. And a gap between what the demonstration showed and what is deployed.
What gets examined
What is deployed
Architecture
Whether the structure supports the growth in the plan, and what the first genuine bottleneck will be. Named, with the load at which it arrives.
Dependency and version risk
What is unsupported, what is end of life, what has known vulnerabilities, and the effort to bring it current. This is the finding that most often moves a number.
Key person risk
How much of the system only one person understands, and whether that person is staying. Measured from commit history and from how the code reads, not from what anybody says.
Engineering practice
Testing, release process, rollback, monitoring, incident history. Whether shipping is routine or an event.
Security and data
Configuration, secret handling, access control, what personal data is held, where it sits, and what obligations follow it.
Licensing and ownership
Open source obligations, third party components, and whether the target actually owns what it is selling. Contractor work without assignment is a common gap.
Cost to operate
What the infrastructure genuinely costs now, and what it costs at the volume in the plan. Frequently different by a multiple.
How the work runs
- Scope and access, day one
What is in scope, what access is granted, and who we may speak to. Access is usually the constraint, and the report states plainly what we were not given.
- Read before asking
The deployed system, the repository, the dependency manifests and the release history first. Questions are better when they are specific.
- Two conversations
One with whoever leads engineering, one with whoever operates the system. They rarely describe the same product, and the gap is informative.
- Quantify the remediation
Every material finding carries an effort estimate and a cost, because a risk without a number cannot be negotiated.
- Deliver to the decision maker
A short conclusion, a risk register ordered by what it does to the price, and the detail behind it for anyone who wants it.
What you receive
A conclusion on the first page
Proceed, proceed with conditions, or do not proceed. With the two or three findings that drive it, stated in a paragraph, not a chapter.
A risk register with numbers
Each risk described, rated by likelihood and impact, and given a remediation cost. Ordered by effect on valuation, not by technical interest.
A first year technology plan
What has to be done post close regardless of anything else, sequenced and costed. This is what turns a diligence report into something the integration team can use.
Questions for the seller
A written list of what we could not establish and what we would want answered before signing. Often the most valuable page in the document.
Reliance stated in writing
Who is entitled to rely on the report, on what date, and against what scope. Agreed before the work starts, so it is not negotiated afterward.
What we will not do
We will not produce a report whose conclusion was decided before the work. If the technology is sound, the report says so, and that is worth as much as the alternative.
We will not opine on legal or financial matters. Where a finding has legal weight, meaning a licensing obligation or a data protection exposure, we describe it and recommend that your counsel look at it. We are engineers.
And we do not accept an engagement where we have a relationship with the target. If we do, we say so and decline.
Timing, and how compressed it can be
Six to fifteen days of effort depending on the size of the target and the access granted. Transactions rarely allow that comfortably, and we can work to a compressed window, though the report will name what was cut.
A three day read on a single application is possible and honest, provided the report says it was a three day read. What we will not do is present a compressed engagement as a complete one.
What we need from you
Read access to the repositories, access to the running system, the infrastructure bill, the dependency manifests, and permission to speak to one or two engineers. Plus the commercial context, meaning what you are paying and what the plan assumes, because a risk is only material relative to a price.
Where access is refused, we proceed and record it. A refusal is itself a finding.
Questions we are asked
How quickly can you start?
Usually within a few working days, and we hold capacity for transaction work because the timing is rarely flexible. Tell us the signing date on the questionnaire and we will say plainly whether we can meet it.
Can our lender or investment committee rely on the report?
Yes, when that is agreed in writing before the work begins. Reliance parties are named in the engagement letter, along with the scope and the date. We will not extend reliance retrospectively.
What if the seller will not grant code access?
We proceed with what is available, usually the running system, the infrastructure and interviews, and the report states clearly what could not be examined and what that means for confidence. A refusal to grant read access is worth recording in its own right.
Do you review the team as well as the code?
We assess engineering practice and key person risk, which is a technical judgment. We do not assess individuals and we do not produce anything that reads as a personnel review.
How is this different from a software audit?
A software audit examines a codebase you already own, to decide what to fix. Due diligence examines a codebase you are considering acquiring, to decide what to pay. The scope overlaps, the reader is different, and diligence carries reliance language that an audit does not.
We are the seller. Can you do this before we go to market?
Yes, and it is often worth more than buy side work. Finding the dependency problem and the licensing gap yourself, then fixing or disclosing them, removes the two things most likely to be used against your price.
What does it cost?
It is quoted per engagement, driven by the size of the target, the number of systems and the timeline. Compressed timelines carry an uplift because they displace other work. A fixed price comes back within two working days of the questionnaire.
Send the questionnaire and we will price it.
About fifteen minutes. A fixed price and a start date usually come back within two working days, from the person who would run the engagement, along with an honest read on whether we are the right team for it.