Developer tools companies can claim the analysis and build experiments, not the plugins, docs or marketing benchmarks
Developer tools companies can claim the R&D Tax Incentive where a tool must achieve something undocumented, such as analysis precision, build correctness or editor latency at a repository scale no published approach covers, and the team tests it against stated thresholds. IDE plugins, SDK generation, docs and marketing benchmarks are routine or excluded.
Reviewed by George WalchFacts last verified
Where the R&D usually sits
For a tools company the unknowns are about code at scale: whether a static analyser can keep false positives below a rate developers tolerate on large real-world repositories; whether an incremental build or type checker stays correct when caches, generated files and toolchains interact; whether a language server can answer within editor latency on a multi-million-line monorepo. The competent professional is an experienced compiler, programming languages or build engineer who knows the research literature and the established open-source tools. If one of those tools already does it at your scale, the work is engineering.
What usually qualifies
Developer tools activities and how they usually fare
Fact
Usually
Why
Designing an incremental type checker that keeps editor feedback under a stated latency on very large repositories
Likely core
Latency and correctness at that scale cannot be predicted from published designs
Building test impact analysis that skips tests while holding a stated missed-regression rate
Often core
Core when the selection method is new; routine when a documented dependency graph approach is applied
Assembling a corpus of real repositories with a scoring harness to measure analysis precision
Supporting
Exists to run and evaluate the core experiments
IDE extensions built on documented editor extension APIs
No
Usually not core; integration following vendor documentation
Generating client SDKs from an API specification with an established generator
No
Not core; known tool, predictable output
Preparing and publishing benchmarks against competing tools
No
Excluded from core as sales promotion (s 355-25(2)(a)); the internal evaluation runs behind them stay with the experiment
Developer surveys and onboarding funnel experiments
No
Excluded from core as market research and market testing (s 355-25(2)(a))
Illustrative example
An illustrative build tool company's cache correctness claim
A hypothetical company sells a build tool for large monorepos. It hypothesised that fingerprinting inputs at file level, including generated files, would keep stale outputs below 1 in 10,000 actions while cutting average incremental build time by a factor of 5, measured over 30 days of commits replayed from three open-source monorepos. Its review of published build systems found no correctness data for that mix of code generators. The first design failed because two toolchains embedded timestamps in outputs. The cache experiment is the core activity, and the commit replay harness is a supporting activity. Its editor extension, docs site and pricing tests are not claimed. This company is an illustration, not a client.
The evidence you already have
Tools companies sit on unusually precise records. Evaluation corpora are versioned, each run produces precision, recall or latency figures per repository, and regressions are caught by CI with timestamps. Design documents and RFCs often state the target before work starts. The gap is usually linking: a run log does not say which hypothesis it tested, so keep the threshold and the corpus version in the same place as the result.
Watch outs
Developer tools claims drift towards the roadmap: "build a faster analyser" is a product goal, not a hypothesis, and in Absolute Vision Technologies the Tribunal rejected software hypotheses framed as goals and documents written after the fact. Selling to developers also invites marketing work that looks technical, such as public benchmarks and comparison tables, whose preparation is sales promotion even when the underlying runs were genuine experiments. And most of a tools company's code (plugins, CLI, docs, billing) is ordinary product work.
A developer tool has an awkward property for an R&D claim: its users are engineers, so almost everything the team does looks technical. The four-part test still asks one question per activity: could an experienced compiler or build engineer, with the published research and the established open-source tools in front of them, have predicted the outcome? For most features the answer is yes. For a handful of hard properties (precision at scale, incremental correctness, latency inside an editor) it is often no, and those are the core R&D activities.
The evaluation corpus is what makes those claims defensible. A fixed, versioned set of real repositories, scored the same way on every run, turns "the analyser got better" into a measured result against a threshold written down in advance. Building and maintaining that corpus is usually the main supporting R&D activity.
Open source and who the R&D belongs to
Plenty of tools companies build in the open. Releasing code under an open licence is not, by itself, a reason a claim fails. What matters is the conducted-for test: the company controls the direction of the work, effectively owns the know-how it produces, and bears the cost whatever happens.
That test is easiest for a project the company maintains and steers. It is harder for contributions to an upstream project governed by others, where maintainers decide what lands and the company's experiment may be one thread in a wider effort. Record which experiments were yours, what you paid for, and what you learned, rather than claiming the project. More on open source.
What does not count, even though engineers built it
Integrations and surface area. AusIndustry's software guide lists integrating services by following vendor documentation and assembling interfaces from known components as routine. Editor plugins, CI integrations and CLI wrappers mostly fall here.
Marketing that looks technical. Benchmarks and comparison tables prepared to sell the product are sales promotion under s 355-25(2)(a). The experiment they draw on is not: claim the runs, not the page.
Developer research. Surveys and onboarding experiments answer market questions, which s 355-25(2)(a) also excludes.
AI features built on a hosted model. Prompting and wiring a vendor's model into a tool is integration. A hosted model can still be one component of a genuine experiment when the unknown lies elsewhere, such as a new retrieval or ranking method. See third-party AI APIs and the AI industry page.
A typical split
One core activity per hard property (for example, analysis precision on large repositories, or incremental correctness under code generation), one supporting activity for the corpus and harness, and everything else left out. If the same corpus serves two core activities, say so in each, and apportion the time of the people who maintain it.
Records matter more than format. AusIndustry expects them to be "created at the time the activity is conducted", and a tools team already has the material: tie each run to the hypothesis it tested.
Frequently asked questions
Is our AI code review feature R&D?
Calling a hosted model and adjusting prompts against its documented behaviour applies a known tool, so on its own it is not usually core R&D. A genuine question can sit next to it, for example whether a new retrieval method over a repository's history cuts false review comments below a stated rate, and that experiment can be core.
Can community contributors' work go into our claim?
No. A claim is built from expenditure the company incurs. Volunteer pull requests cost the company nothing. A contributor the company pays under an agreement is a contractor, and the share of what was paid for registered activities can be claimed, though work done overseas also needs an overseas finding.
Our benchmarks page shows us beating competitors. Is that evidence?
The page itself is not. Preparing and publishing comparisons to sell the product is sales promotion, excluded from core. Publishing does not change what the original evaluation runs were: runs made before you knew the answer, with the threshold written down first, remain evidence for the experiment, even after the numbers are published.
The R&D Tax Incentive is a self-assessment program. This page is general information, not tax, legal or financial advice; eligibility depends on your circumstances and you should seek independent advice for them.
