Can Software Development Qualify for R&D Credits?

Computer software can be a business component under Section 41. That does not make every software task qualified research: the work still needs to meet the four-part test and avoid applicable exclusions.

Building or improving software may support a credit when the taxpayer can show qualifying uncertainty, a process of experimentation, eligible expenses, and the other required facts.

• Building new product features that involve architectural decisions, performance trade-offs, or integration challenges
• Developing internal tools with novel technical approaches (not just configuring off-the-shelf software)
• Performance optimization when the solution isn't obvious and requires experimentation
• Data pipeline engineering involving scalability, reliability, or latency challenges
• Security implementations addressing novel threat models or encryption approaches
• API design and integration where the approach to interoperability isn't straightforward
• Machine learning model development including feature engineering, architecture selection, and training optimization
• DevOps and infrastructure work when solving scaling, reliability, or deployment challenges with uncertain outcomes

• Routine bug fixes with known solutions (stack overflow copy-paste)
• Simple CRUD operations following established patterns
• UI styling changes that are purely aesthetic (not functional)
• Installing or configuring off-the-shelf software
• Routine maintenance and updates (dependency bumps, etc.)
• Project management and non-technical planning
• Market research and user surveys
• Documentation of already-completed work

The line between qualifying and non-qualifying isn't always obvious. A bug fix that requires understanding a race condition and experimenting with synchronization approaches might qualify. A bug fix where you know exactly what's wrong and change one line does not.

A critical point: the IRS does not require that your work be new to the industry or represent a scientific breakthrough. The standard is "new or improved" from the taxpayer's perspective. If your team faces genuine uncertainty about how to build something — even if other companies have solved similar problems — the work can qualify.

The facts should be documented at the business-component level. A familiar problem domain does not resolve the question by itself.

The IRS expects evidence that each qualifying project met the four-part test. For software teams, the strongest evidence comes from:

• Git commit history — shows what was attempted, when, and by whom
• Branch and PR strategies — demonstrate experimentation with alternatives
• Design documents — capture uncertainty at the outset
• Code review comments — show technical evaluation of approaches
• Time tracking data — ties developer hours to specific projects

These records can be useful when they explain the business component, uncertainty, alternatives, and expense connection. QuarryFi organizes references for review; it does not make the final eligibility determination.