Technical Due Diligence for Hardware, IoT and Software Companies

What we do

We review the thing itself rather than the description of it. Architecture and where it will break under the growth in the plan. Engineering practice and how much knowledge sits undocumented in individual heads. Security and data exposure. For hardware and silicon targets, the test evidence, the qualification flow, the manufacturing and supply position.

Then we map each claim in the materials to the evidence behind it, and we say plainly which ones are supported, which are partly supported, and which are assertions.

Where we are unusual

Most diligence teams are software people. When the target is a chip company, a device company or anything with physics in it, the review stops at the architecture diagram.

We have taken on space-grade semiconductor diligence, including radiation evidence, qualification flow and flight heritage. The same depth applies to boards, embedded systems and the manufacturing position behind them.

What we review in a connected-device company

The board: single-source and end-of-life components, design margins, and whether the design files actually match what the factory builds. The firmware: how it is updated in the field, whether updates are signed, how the bootloader recovers from a failed update, and how much of it is tested.

The link from device to cloud: provisioning, fleet management and what happens when a batch of devices goes offline. The cloud backend and its cost at the scale in the plan. And the position behind all of it: certification status such as FCC and CE, contract manufacturing, and who holds the design files.

How the engagement runs

Scoping first, because the questions an investor needs answered differ from the questions an acquirer needs answered, and the difference changes what we look at. Then the review itself, working from code, test data and the people who built it.

The deliverable is a structured assessment you can hand to an investment committee, with the method visible so someone can disagree with a conclusion on its reasoning rather than on its tone.

WHAT THIS RESTS ON

Hardware and silicon

Including radiation evidence, qualification flow and supply position

Regulated systems

GxP, HIPAA and prudential assurance platforms built, not just reviewed

Claim to evidence

Every claim mapped to what supports it, or marked as unsupported

How we engage

Team: A dedicated pod, billed monthly, with a three-month minimum.
Starting: Within one to two weeks of agreeing what gets built, what gets left out, how payments work, and the roadmap after launch.
Working hours: 7am to 8pm IST, with calls until 10pm IST. That covers the US Eastern morning.
Ownership: All code and IP are yours on payment.
Architecture only: We can design the architecture for a team you already have. Your team then owns delivery. We take responsibility for execution only when our own team builds it.

Questions we hear before engagements

How fast can you turn one around?

It depends on the target’s complexity and how much access we get. We will tell you at scoping what is achievable in your window and what would have to be left out.

Will you say the deal is bad?

We will say what we found. A report that only ever confirms the thesis is not worth commissioning, and the findings that change a decision are usually the ones nobody wanted.

Who usually commissions this?

Private equity firms, venture investors and strategic acquirers before a deal, and lenders who want the technology risk understood before they commit.

Can you review firmware and hardware as well as the software?

Yes, and in one engagement. Most diligence teams stop at the software. For a device company the risk often sits in the board, the firmware update path or the manufacturing position.