If you are paying to have software built, modernized, or rescued, there is a fair chance the federal government will give some of that money back. The research and development tax credit is not just for labs and manufacturers. Custom software is one of the most common things it is claimed on, and most of the owners we work with have never been told that.
This post explains what the credit is, how the test works, which of our kinds of projects tend to qualify, and where the catches are. It is not tax advice. We are a software firm. What follows is what we have learned working alongside our clients’ tax partners on their claims, and the questions that come up every time.
What the credit is
The federal credit lives in Section 41 of the tax code. It rewards a business for spending money on developing or improving something technical, and it does so as a credit, not a deduction. A deduction lowers your taxable income. A credit comes straight off the tax you owe.
How much? It depends on the method your CPA uses and on your history of research spending, but for most companies it works out to somewhere in the mid single digits to around ten percent of the qualified spend. On a $300,000 software project, that is real money. Many states add a credit of their own on top. Texas has one, tied to the franchise tax, and it was restructured in 2025 with the new rules taking effect in 2026.
The four-part test
The IRS asks four questions about an activity. If the answer to all four is yes, the spending on it can count.
- Permitted purpose. Was the work meant to create new or improved functionality, performance, reliability, or quality of a product, process, or piece of software? Building an application your company did not have before is the clearest yes there is.
- Technological in nature. Did the work rely on the hard sciences? Computer science and engineering count. Software development is squarely inside this.
- Elimination of uncertainty. At the start, was it unclear whether you could build it, how you would build it, or what the right design was? On a custom project the answer is almost always yes. If everyone knew exactly how to do it on day one, it would not be custom.
- Process of experimentation. Did the team evaluate alternatives, build and test, and refine? Prototypes, design iterations, integration attempts that failed and were reworked, load tests, the sprint-by-sprint cycle itself. That is the process the IRS is describing.
Notice what the test does not require. The work does not have to be new to the world, only new to you. It does not have to succeed. A project that shipped late, got rescued, or was partly rebuilt still qualifies for the effort spent on it.
Which projects usually qualify
Across the work we do, these tend to clear the test comfortably:
- A new application built for how your business runs. Uncertainty and experimentation are the whole job.
- Modernizing or rewriting a system you have outgrown. Moving to a new architecture, replacing a dead framework, re-engineering how data flows. The experimentation is in the migration, not just the end product.
- Rescuing a project that went sideways. Diagnosing, stabilizing, and re-engineering what someone else built involves plenty of uncertainty.
- Integrations and data platforms that connect systems that never talked, with the design and testing work that takes.
- Mobile apps for the field, especially where offline behavior and syncing have to be worked out.
- AI and automation wired into your systems, where prompts, models, guardrails, and workflows get tried, measured, and revised.
Where the bar is higher
Two areas deserve a closer read with your tax partner.
Software you use only for back-office functions. The rules treat software built for general and administrative work, such as finance, HR, or internal support, as “internal use software” and hold it to three extra tests: it has to be genuinely innovative, involve significant economic risk, and not be something you could have bought. Software that runs your operations, serves customers, or lets outside parties interact with you is not held to that bar. A customer portal, a dispatch platform, a quoting tool, a field app: normal test. A homegrown expense-approval workflow: higher bar.
Work that is routine after launch. Bug fixes, minor tweaks, and ordinary maintenance once a system is in production do not qualify. Nor does configuring an off-the-shelf product, market research, or user surveys. The line is technical uncertainty. Enhancements that require real engineering can qualify; keeping the lights on does not.
What you can count
Qualified spending on a software project generally includes:
- Wages for your own people who do, supervise, or directly support the development
- Supplies and cloud computing used in development
- 65 percent of what you pay an outside firm like us to do the work
That last one matters if you are hiring a firm rather than a team. It comes with two conditions. You have to keep substantial rights to what gets built, and you have to be the one bearing the financial risk, meaning you pay for the work itself, not only for a result promised in advance. Our agreements are written that way: you own the code, the IP, and the data, and our statements of work pay for the effort. Your CPA will want to read the contract to confirm it. One more condition: work performed outside the United States does not count toward the federal credit. Ours is done by our own team in Texas.
What changed in 2025
For three tax years, 2022 through 2024, a change in the law forced companies to spread the deduction for domestic research spending, including software development, over five years instead of taking it in the year they spent it. That made a lot of software projects more expensive on an after-tax basis, and it surprised plenty of owners at filing time.
The law passed in July 2025 restored immediate expensing of domestic research costs for tax years beginning after December 31, 2024. Companies with average annual gross receipts of $31 million or less can elect to apply it retroactively to 2022, 2023, and 2024 by amending those returns. Larger companies can recover the amounts still unamortized over one or two years. If you built software in those years and your CPA has not raised this, it is worth a call.
What to do with this
If you are planning a project, ask your CPA before you sign whether they will want to treat it as qualified research, and tell your software firm so the documentation exists from day one. If you have already built something in the last three years, ask whether an amended return is worth it. The window to go back is generally three years.
The next post walks through the claim itself: the process, the documentation, and the form. The one after it covers what a software firm should be handing you so the claim is easy.
This is general information, not tax advice. Talk to your CPA or a credit specialist about your situation.