Exactly. We would love software development to be as simple as: you pay $1m to engineers to develop a software machine; you now have a $1m software machine that you can pay nonengineers to operate and crank out revenue.

In practice software machines need constant tending and operation by engineers in order to keep them pumping out money.

In the context of live software systems, a lot of software engineering - even engineering that involves innovation and creative research and problem solving - is done in service of making the machine continue to operate; it is operational expense.

It’s like: Buying some filing cabinets is clearly a capital expenditure. But paying an office administrator to come up with and keep modifying the filing system you use in those filing cabinets to make sure it continues to serve your business is not capital investment, it’s business operational costs.

If you buy a building, it is a capital expense that depreciates over years, even though you absolutely have to keep paying for maintenance. Why should software be different?

Unlike a building—where you might find one for sale and simply buy it—most companies don’t "buy one software" from a vendor and amortize it like a purchased asset. Instead, they hire full-time teams to build, maintain, and evolve software as a core, continuous function of the business. And most companies don’t "sell one software" either—they lease it to others, as software-as-a-service.

In your analogy, when a company constructs and sells a building, labor costs are deductible as part of the cost of goods sold. Only the profit—when the finished product is sold—is taxable. But under the new Section 174 rules, software R&D labor is treated like the purchase of a capital asset, even though the company is leasing a service, not selling a final, tangible product.

The flaw? Software isn’t a static, finished asset you walk away from. It’s a living system. One update might fix a bug, introduce a feature, and improve long-term architecture all at once. Is it maintenance? Innovation? Infrastructure? The answer is usually “all of the above.” So how does anyone report that cleanly on a tax form? What’s the IRS’s standard test for sorting that out?

Before TCJA, some companies may have stretched R&D definitions to claim Section 41 credits. But after the TCJA change, the incentive flipped. Now, companies are penalized for doing real R&D—the very thing we should be encouraging. Startups are now paying painfully high tax bills simply for building something they cannot lease out en masse yet.

We should want to incentivize invention, not suppress it. We need more startups, not fewer. Software—especially with generative AI—is one of the few options for us left that can create new markets, expand GDP, and drive compounding national growth. The upside is limitless. This is hammering our economy and it’s strangling startups at the exact moment we need them most.

Congress, do the right thing; restore the rules we had pre-TCJA.

Timeline:

- 1981: Section 41 introduced — provides tax credits for qualified R&D activities.

- Pre-2018: Under Section 174, R&D expenses (including software) were fully deductible; Section 41 credits could be claimed.

- 2017 (Dec): TCJA passed by the 115th Congress and signed by President Trump; Section 174 expenses to be amortized over 5 years starting in 2022.

- 2022: Amortization rule takes effect. Companies must now capitalize and amortize R&D expenses.

- 2025: Section 174 amortization remains in effect; Section 41 credits still exist but now come with a steep tradeoff.

But the idea behind capitalizing research and development is to eliminate the difference in financial presentation between buying and building software. In both cases, one pays cash to acquire the software then uses it over a period of time to generate revenue. Purchased software is clearly capitalizable. It is then amortized over the expected useful life of the software. Annual maintenance fees are not capitalizable as they are not expected to extend the useful life of the software. Allowing R&D to be capitalized just evens the playing field.

If R&D were not allowed to be capitalized, then a company would have an incentive to create a specific entity to develop its internally used software, then sell that software to parent company. If it set up the entities properly, it would capitalize the software as purchased software rather than R&D. Many firms with international development teams do this to manage in what country they pay taxes - the goal being to derive no value in high-tax countries and high value in low/no tax countries.

Thanks for the perspective—makes sense from a financial reporting lens. Curious how you'd balance that with the reality that modern software is rarely a finished asset, and startups often don’t have revenue yet when these costs hit.

if I pay a bunch of employees to take the cloth I buy and cut and sew into shirts, that's an expense some directly out of my revenue and isn't taxed as profit or forced to be amortized. Why should software be different?

I suppose it depends. Are you making shirts to sell, or to use in your business? One is inventory, one is a capital expense.

Many people use depreciation and amortization interchangeably. From an accounting perspective one uses depreciation for tangible assets (can be touched and seen e.g. machinery) and amortization for intangible assets (e.g. trademarks and R&D). Depreciation and amortization behave the same way - they decrease an asset by expensing a portion of it on a regular basis.