Technical due diligence is an independent engineering review that answers one question: does the technology do what the people presenting it say it does, and what will it cost to get from here to production? It is commissioned by investors before a round, by acquirers before a purchase, by licensees before signing, and increasingly by founders themselves before they commit to a design they inherited. Unlike financial diligence, it cannot be done from documents alone — somebody has to look at the CAD, read the firmware, examine test data, and put hands on the hardware.

When you need one

  • Before investing in a hardware company. The pitch says the prototype works. Diligence establishes whether it works repeatably, whether it can be manufactured at the claimed cost, and how much engineering remains.
  • Before acquiring a product line. You are buying drawings, tooling, suppliers, and firmware. Any of those can be missing, undocumented, or owned by someone else.
  • Before licensing a technology. Royalties are paid on units shipped; if the design cannot be manufactured at volume, the license is worthless.
  • Before you take over a project. Founders who inherit a design from a previous team, or who are considering switching engineering firms mid-project, need an honest baseline of what actually exists.
  • Before a major production commitment. Cutting steel for tooling makes design debt permanent and expensive.

The engineering checklist

Does the core claim hold up?

Identify the one or two technical assertions the whole business rests on — the sensor resolution, the battery life, the throughput, the accuracy — and check them against measured data taken under stated conditions. Demonstrations are staged; test reports with methods, sample sizes, and raw data are evidence. Absence of data is itself a finding.

Design maturity

Which stage is this really at? A working benchtop rig, a looks-like model, and a design that has passed engineering validation are three very different assets. The EVT, DVT, and PVT framework gives a common vocabulary for placing a project honestly on that timeline.

Documentation and transferability

Can another competent team continue this work? That means native CAD files and not just exported STEP, schematics and PCB source, firmware source with a build that actually compiles, a complete bill of materials with real part numbers, and test procedures. The full package is described in our guide to the manufacturing data package — its absence is one of the most common and most expensive findings.

Cost and manufacturability

Rebuild the unit cost from the BOM plus process, labor, yield, and scrap assumptions, and compare against the claimed cost. Then review whether the design can be made at the intended volume at all: draft, wall thickness, tolerances, part count, assembly sequence, test fixtures.

IP position

Which filings exist, who owns them, are they in force, and do they cover the product as designed or an earlier concept? Separately, is the company free to sell — a question answered by a freedom-to-operate search, not by owning patents of your own. Also check ownership of work done by contractors, which is frequently the weakest link in a young company's IP position. This is engineering assessment of technical scope, not legal opinion — Projects House is an engineering firm and IP validity questions belong with a patent attorney.

Regulatory and standards path

Which approvals apply, what has been tested, and what is assumed? Radio certification, safety listings, medical classification, and children's product rules each carry schedule and cost that are frequently missing from plans.

Supply chain and single points of failure

Sole-source components, parts near end of life, tooling held by a factory rather than the company, and undocumented process knowledge sitting in one supplier's head.

Risk register and remaining work

The output should include a realistic estimate of engineering months and spend to reach production, with risks ranked by impact — the same discipline described in risk management in product development.

Red flags that recur

  • A demo that only the inventor can operate, or that must be "warmed up" first.
  • No written test protocol, and results reported as impressions rather than numbers.
  • CAD that exists only as meshes or PDFs, with no parametric source.
  • Firmware with no version control history and no reproducible build.
  • A unit cost derived from a single quotation at a volume nobody has ordered.
  • Schedule compression that assumes every certification passes on the first attempt.
  • Reluctance to allow the reviewer to disassemble a unit or speak to the engineers directly.

What you receive, and who should do it

A useful deliverable is short and blunt: a summary verdict, findings ranked by severity with evidence for each, a corrected cost model, a remaining-work estimate in engineering months and dollars, and a list of conditions that would change the verdict. Timelines typically run one to three weeks for a focused review, longer for multi-discipline systems, with cost in the range of a few weeks of senior engineering time — trivial against the size of the decisions it informs.

The reviewer must be independent of the design team and must actually cover the relevant disciplines: mechanical, electronics, firmware, and manufacturing. A single generalist reading slides is not diligence. If you are also assembling the wider picture, our investor due diligence checklist covers the non-technical workstreams, and product engineering companies explains how firms like ours are structured.

Commission a review

Projects House performs technical due diligence for investors, acquirers, licensees, and founders, across mechanics, electronics, firmware, and manufacturability. Tell us through the contact form what you are evaluating and by when, and we will scope a review that fits your decision timeline.