Technical due diligence, in writing.

Who it's for

Four people ask for this, for the same reason.

Somebody is about to commit money to software they cannot read. The questions are always the same — is it sound, what is it hiding, what breaks when this grows, and what will the fixing cost?

• Venture investors — a term sheet is moving and the technical diligence so far is a founder demo and a vendor scan.
• Private equity and acquirers — the value-creation plan assumes a roadmap the engineering org may or may not be able to deliver.
• Boards and operators — a company you already own needs an independent read before the next raise, the next hire, or the next rewrite.
• Founders being diligenced — you would rather find what they will find, first.

After the deal closes

The same discipline applies post-acquisition, when the roadmap you underwrote isn't shipping and nobody can say whether the cause is architecture, process, or people — that read is an engineering audit rather than diligence, but it's the same written, ranked verdict. A fractional engagement can then own the fix — one firm, one throat to choke, no handover between the reading and the doing.

What gets read

The code, and everything around it.

A codebase alone is a poor predictor. What a system does under growth is decided as much by the team's habits and the delivery record as by the source — so all of it gets read.

• The source — architecture, data model, test coverage and what it actually covers, the shape of the dependencies.
• The history — commit and release record, incident history, what the migrations say about how decisions really got made.
• The infrastructure — environments, deployment, monitoring, the recovery story, and where the single points of failure live.
• The integrations — third-party and partner dependencies, and how the system behaves when one of them misbehaves.
• The team — seniority, bus factor, who holds the knowledge nobody wrote down, and whether the org can deliver the plan you are underwriting.
• The security and compliance posture — as it bears on the deal, not as a substitute penetration test.

The deliverable

A written verdict, signed by the person who read it.

The output is a document, not a call and a vibe. It answers four questions plainly enough to forward to an investment committee:

• What's sound — what genuinely works, and where the engineering is better than the pitch suggested.
• What's debt — deliberate shortcuts, undocumented entropy, and the difference between the two.
• What breaks at 10x — the constraints that bind first when volume, headcount, or scope multiply.
• What it costs to fix — in effort and sequence, so the number can go into a model.

Findings are ranked, not listed alphabetically: a diligence report whose reader can't tell the deal-breakers from the nits hasn't done its job. Reports are prepared for the engaging party.

How it runs

Scoped in writing, then read.

1. A 30-minute call

   The deal, the clock, and what a useful answer would look like. An NDA comes first if you need one.

2. A fixed-scope proposal

   What will be read, what the report will contain, the window it lands in, and a fixed price — in writing, within 48 hours of the call. No hourly billing, so there is no meter to watch.

3. Access, then the read

   Read access through your systems or the target's, revocable by you at any time. Interviews with the engineers if the deal allows it — the ten minutes with a lead engineer often outweighs a day in the repository.

4. The verdict

   The written report, followed by a call to walk the findings and answer the question that always arrives after: so do we proceed?

Diligence moves at deal speed — the window is agreed on that first call and written into the scope.

The shape of it

How this engagement usually goes.

Client work is confidential by default, so what follows is pattern, not portfolio — the engagement as the firm runs it. Named references are shared in conversation.

Why this firm

No bench to sell you, no incentive to inflate.

An engineering firm that also staffs remediation has a quiet reason to find expensive problems. Prayantr is principal-led and takes few engagements at a time — the person who reads the code is the person who signs the verdict, and there is no bench waiting to be sold into the fix. Two decades of platform and integration engineering sit behind the reading; more on the entity and the person on The Firm, and the full career record at amitsolanki.com.

Confidentiality runs both ways: NDA before any deep conversation, access revocable by you at any time, and nothing about your deal published anywhere — the same discretion that keeps other clients' names off this site's work page.

MSA + SOW on every engagement · Fixed scope, fixed price, no hourly billing
NDA on request · IP assigned to you on payment · USD invoicing, worldwide