The R&D Test Everyone Gets Wrong: Technical Risk, Not Market Risk

Ask a founder whether their work is “risky R&D” and they’ll usually tell you about the market: will customers adopt it, can we scale, will the unit economics work. All real risks — and all the wrong answer for an R&D claim.

Across every major R&D tax credit regime, the uncertainty that qualifies is technical, not commercial. The question isn’t “will this succeed in the market?” It’s “can this be built at all, with the knowledge available?”

The distinction

• Technical risk — you don’t know whether the technology can be made to work. The feasibility is genuinely uncertain; a competent professional couldn’t just look it up or deduce it. *This qualifies.*
• Market risk — you know the technology works, but you don’t know whether anyone will buy it, whether you can sell it profitably, or whether you can scale production. *This doesn’t qualify*, however large the risk.

A company can carry enormous market risk and do zero qualifying R&D — a well-understood product in an unproven market. Another can carry modest market risk and do deep R&D — a known demand, but no one yet knows how to build the thing that serves it.

Why deep-tech teams trip on it

Deep-tech blurs the two because the technical and commercial risks are often both severe at once. That’s exactly why the distinction matters: when you document your R&D, you have to isolate the *technical* uncertainty and evidence it specifically. “This market is unproven” is not a qualifying narrative. “We did not know whether this material could hold its structure under these thermal loads, and resolved it through iterative testing” is.

The cleanest way to find the line is to ask your engineers, not your investors: *had this been done before, in a way a competent practitioner could reproduce?* If no, you likely have qualifying technical uncertainty. If the only honest unknown is whether it’ll sell, you don’t — no matter how much money is on the line.

What this means for your claim

When you build the evidence behind a claim, tag the work by the uncertainty it resolved. The hours spent proving technical feasibility are the claimable ones; the hours spent on market validation, however essential to the business, are not. Keeping those separable — as the work happens — is what lets you claim confidently and defend the claim if it’s ever questioned.

That’s the recurring theme across funding for deep-tech: the rules reward proof of *technical* problem-solving. For the full picture of what qualifies and how to document it, see what counts as R&D.