When most people think about Research and Development (R&D) in a SaaS company, their minds go immediately to software engineers writing code. And while engineering is certainly at the heart of it, limiting your understanding of R&D to lines of code can cause companies to overlook significant portions of qualifying work—and leave meaningful tax credits or innovation incentives on the table.
R&D incentives, including the U.S. federal R&D tax credit, are designed to reward companies engaged in innovation and technical problem-solving—not just those running formal laboratory experiments. For SaaS companies, this means a wide range of activities across multiple departments can potentially qualify, as long as they meet the underlying criteria for what makes work truly “research and development.”
This guide explores what qualifies as R&D in SaaS beyond the engineering core, and why understanding the full scope of qualifying activities matters for your business.
The Core Criteria: What Makes Work “R&D”?
In the U.S., the IRS uses a four-part test to determine whether an activity qualifies for the R&D tax credit. These criteria form the backbone of how R&D is defined across industries, including SaaS:
- Qualified Purpose: The work must aim to develop or improve a product, process, or piece of software. It doesn’t need to be a brand-new product—improving an existing one counts.
- Elimination of Uncertainty: There must be a genuine technical challenge or unknown. If the answer is already known and the path to solution is clear, it’s not R&D.
- Experimentation: The process must involve systematic trial and error, prototyping, or iterative testing to evaluate different approaches.
- Technological in Nature: The work must rely on principles of engineering, computer science, or a related technical discipline.
Critically, these tests do not require a formal lab setting or advanced physics research. Software development that meets all four criteria qualifies. And so can many activities that happen outside the engineering team.
Engineering at the Core (But Not the Whole Story)
Before expanding to other departments, it’s worth acknowledging the engineering activities that most commonly qualify:
- Developing new product platforms or novel multi-tenant architectures
- Improving scalability and performance through experimental approaches
- Security enhancements that address unresolved technical unknowns
- Developing algorithms, building API integrations, and creating features that present genuine technical challenges
These activities are foundational—but they don’t tell the whole R&D story for most SaaS companies.
Beyond Engineering: Broader Qualifying Activities
Many SaaS companies are surprised to learn that qualifying R&D work often extends well beyond their engineering teams. Here’s a closer look at the areas that are frequently overlooked:
1. Product Management & Requirements Work
Product managers play a crucial but often invisible role in R&D. When a product manager is conducting detailed user needs analysis or defining functional specifications that shape technical solutions—particularly when those decisions carry meaningful technical uncertainty—that work can qualify.
For example, if a product manager is defining requirements for a new recommendation engine and those requirements directly influence how engineers design the underlying algorithm, the requirements analysis can be considered part of the R&D process. The key is the link between the analytical work and the experimental technical decisions it informs.
2. Design & Systems Architecture
Design work—especially at the systems level—can be a hotbed of qualifying R&D activity. When a solutions architect or senior engineer is evaluating competing architectures (such as microservices versus a monolithic system) with genuinely uncertain outcomes, that analysis involves real technical experimentation.
The logical and physical design of how a SaaS system will meet performance, reliability, or scalability goals often involves unknowns that are resolved through prototyping and iteration. This kind of design work can absolutely qualify under the R&D criteria.
3. Testing, Integration & Iteration
Quality assurance and integration testing are areas where a lot of qualifying work goes unclaimed. When engineers and QA professionals are integrating with third-party systems and that integration reveals unknown technical behavior—or when performance and regression testing involves genuine technical decision-making—those activities meet the experimentation criteria.
Complex QA workflows that require evaluating how the product behaves under varying conditions, and determining which approaches resolve the underlying technical questions, are core to the R&D process—even if they happen after the initial code is written.
4. Internal Tools & Process Development
Many SaaS companies build internal tooling to support their own operations—custom CI/CD pipelines, build automation systems, infrastructure orchestration tools, and more. When this internal development involves genuine technical uncertainty and experimentation, it can qualify as R&D, even though it doesn’t directly become a commercial product.
The question is whether the work required the company to resolve technical unknowns through systematic experimentation. If the answer is yes, the fact that the output is an internal tool rather than a customer-facing feature doesn’t disqualify it.
What Generally Does Not Qualify
Understanding what falls outside the definition of R&D is just as important as knowing what qualifies. The following activities are generally excluded:
- Routine maintenance and bug fixes that don’t involve technical uncertainty—if the solution is already known, it’s not R&D
- Cosmetic UI changes or standard updates implemented using well-established methods
- Marketing, sales strategy, and customer outreach, even when they involve creative problem-solving
- General business documentation unrelated to resolving technical problems
The common thread among non-qualifying activities is the absence of technical uncertainty. If the team already knows how to accomplish the goal and the work doesn’t involve genuine experimentation or problem-solving in a technical domain, it’s unlikely to qualify.
Cross-Functional R&D in Practice
To make this concrete, consider two examples of cross-functional R&D that span multiple teams:
Cross-disciplinary product experimentation: A product team identifies a customer need for intelligent search within the platform. The product manager defines functional requirements, the design team evaluates UX approaches with uncertain outcomes, and engineers prototype multiple ranking algorithms before one proves effective. All three teams contributed to qualifying R&D work.
Platform reliability projects: A reliability initiative involves architects evaluating infrastructure options, engineers building experimental deployment pipelines, and QA teams running stress tests to identify failure thresholds. This kind of coordinated effort—spanning design, development, and testing—can generate substantial qualifying R&D across the organization.
How to Document Qualified R&D Beyond Coding
Claiming R&D credits or incentives requires substantiation—and the documentation challenge grows when R&D spans multiple teams. Here’s what to focus on:
- Time and project tracking: Employees across engineering, product, design, and QA should track time against specific R&D projects. Even approximate allocations, consistently maintained, can support a claim.
- Technical plans and decision logs: Architecture decision records, sprint notes, design specs, and technical design documents demonstrate that qualified activities occurred.
- Testing results and performance data: Logs from experiments, benchmark results, and integration test outcomes provide evidence of systematic experimentation.
- Requirements and analysis documentation: Product management deliverables that link directly to technical questions and decisions help establish the connection between non-engineering roles and qualifying R&D work.
Conclusion
R&D in SaaS is not just about engineers pushing commits. It’s about the entire problem-solving process—from initial product requirements through design, experimentation, integration, testing, and internal tooling—whenever that process is driven by genuine technical uncertainty and systematic experimentation.
For many SaaS companies, recognizing the full breadth of qualifying R&D work means a significantly larger portion of the organization’s effort counts toward innovation incentives. Taking a cross-functional view of R&D isn’t just good practice for tax purposes—it’s an accurate reflection of how innovation actually happens in modern software companies.
If you haven’t already, it’s worth conducting a thorough R&D review with qualified advisors who understand both the technical and tax dimensions of what you’re building.
