How to recognize a strong software development SR&ED claim

Not every company that "does software" is doing SR&ED. Conversely, many strong claims go unnoticed because the client describes the work in business terms rather than technical ones. Your job isn't to judge the code, but to spot the presence of an experimental process facing a technological uncertainty. A few questions and signals are enough to guide the decision.

The core criterion: technological uncertainty

SR&ED doesn't reward effort, commercial novelty or perceived complexity. It rewards having faced a technological uncertainty that couldn't be resolved simply by applying known practice. The question to keep in mind: "Would a competent developer in the field have known in advance how to get there?" If the answer is no, it's worth digging.

Five signals of a strong claim

• The team had to experiment. Several approaches were tried, compared, sometimes abandoned. The project didn't follow a straight line.
• They talk about technical limits. Performance, scaling, latency, model accuracy, hardware or integration constraints that resisted the usual solutions.
• Existing documentation or libraries weren't enough. The team had to build something where off-the-shelf tooling stopped.
• There were real failures. Versions that didn't hold up under load, results below expectations, rewrites. That's a good sign, not a bad one.
• Developers light up when they talk about it. The "real" technical problem is often the one the team discusses with passion or frustration.

Five signals that should make you cautious

• "We just assembled existing tools." Integrating proven components in their intended way is generally not R&D.
• The whole story is commercial. If the client only describes features and customer benefits, with no technical obstacle, the claim is fragile.
• "It was long, but not really hard." Volume of work doesn't create eligibility; uncertainty does.
• Configuration and customization. Configuring a platform, wiring documented APIs or styling an interface rarely qualifies.
• No trace at all. No version control, no tickets, no notes: even a good project becomes hard to defend.

A useful shortcut: ask "What could have failed, and why weren't you sure it would work?" The quality of the answer reveals, in about a minute, whether there's a claim.

A good project isn't always a good claim

A project can contain genuine R&D and still be hard to claim if the evidence is missing or if the uncertainty is buried in routine work. Conversely, a modest but well-bounded project, with a clear trace of attempts, often yields a cleaner claim. The ability to isolate and document the eligible portion matters as much as the presence of uncertainty.

When in doubt, validate before investing

When a file is ambiguous (common in SaaS, platforms and AI), a short technical conversation with the client's team clears it up quickly. That's exactly what I do for firms: a first-pass technical opinion that saves you from committing time to a fragile file, or confirms it's worth going further.