SaaS companies — firms that develop and operate software-as-a-service products — may perform activities that warrant analysis under the federal R&D tax credit. This page explains what development work may be relevant. It is educational and is not individualized advice. For the foundational framework, see our page on qualified research.
What R&D May Look Like in SaaS Companies
SaaS development may involve architecture, scalability, algorithms, integration, reliability, and security. Work directed at resolving genuine technical uncertainty in these areas may warrant review. Routine coding, configuration, and feature development using established methods do not, by themselves, constitute qualified research.
Industry-Specific Examples of Technical Development
- Evaluating alternative software architectures to resolve a question about whether a system can achieve a target scale, performance, or reliability where the appropriate design is uncertain.
- Developing or evaluating algorithms to resolve a technical question about capability or performance where the appropriate method is uncertain.
- Resolving integration uncertainty where combining systems raises a technical question not established at the outset.
- Engineering for reliability or performance where the appropriate design is uncertain and is evaluated through testing.
- Developing security engineering approaches to meet a specified target where the appropriate method is uncertain.
- Developing data-processing approaches to handle scale or complexity where the appropriate approach is uncertain.
Technical Uncertainty Examples
- Whether an alternative architecture can achieve a specified scale or performance target.
- Whether a new algorithm can achieve a specified accuracy or latency target.
- Whether an alternative integration approach can resolve a technical question about system capability.
Process-of-Experimentation Examples
A process of experimentation may involve modeling or simulating alternative architectures and measuring performance, benchmarking alternative algorithms and evaluating results, or systematically testing competing approaches and measuring performance.
Potential Business Components
Potential business components may include a new or improved SaaS product, a new or improved architecture, a new or improved algorithm, a new or improved integration approach, or a new or improved reliability or security approach.
Employee and Contractor Work
Employees whose work may warrant analysis include software architects, developers, data engineers, site-reliability engineers, and security engineers. Contractor work may include outside developers or consultants performing development work on behalf of the company — where the company bears the economic risk and retains substantial rights.
Activities That Generally Require Caution or May Not Qualify
- Routine coding and feature development using established methods.
- Configuration of off-the-shelf software or platforms.
- Routine bug fixes and maintenance.
- Cosmetic UI or UX changes without a technical performance target.
- Ordinary troubleshooting or debugging.
- Market research or user testing without a technical development question.
Documentation That May Help
Records that may help include architecture evaluation records, algorithm benchmarking data, integration test results, performance and reliability test data, and records connecting personnel to specific development projects.
Example Hypothetical Project
The following is a hypothetical example for illustration only.
A SaaS company is evaluating alternative architectures to determine whether its platform can achieve a specified scale and performance target for a new enterprise use case. The technical uncertainty is whether an alternative combination of architecture, data-processing approach, and caching strategy can achieve the specified target. The team models alternative architectures, benchmarks performance, and conducts load testing. Professional review is still needed.
Questions to Ask Internally
- What specific product, architecture, or algorithm was being developed or improved?
- What technical uncertainty existed at the outset?
- How does this differ from routine coding or configuration?
Relationship to the Four-Part Test
The four-part test applies the same way as in any industry. The work must satisfy all four elements: permitted purpose, technological in nature, elimination of uncertainty, and process of experimentation. Internal-use software may be subject to additional requirements; see our page on internal-use software. For more on software activities generally, see our page on software development and the R&D tax credit.
Key Takeaway
SaaS companies may perform activities that warrant analysis under IRC §41 — particularly work involving architecture, scalability, algorithms, integration, reliability, and security. Routine coding and configuration do not automatically qualify. Because these determinations are fact-specific, professional review is appropriate. For related industries, see software development and the R&D tax credit and custom software development.