A Hacker News self-post organizing grassroots advocacy for US tax policy change (Section 174 software development expense deductions). The post exemplifies Articles 19–21 by providing transparent mechanisms for citizens to petition lawmakers, explicitly respecting disagreement, and enabling democratic engagement through a community-organized letter campaign. Human rights content is instrumental rather than substantive—the post leverages democratic rights to advocate for economic policy.
Thanks for working on this guys. The current tax code is fairly crazy: you could spend a few million in salaries, sell 200k of software in a year and possibly owe taxes on that. Even if the company would otherwise be shutting down.
The traditional capital asset treatment applied to software leaves a lot to be desired. Some software is a capital asset, but much just isn’t. Or at least should be considered to depreciate rapidly.
As a business owner, I've been adversely impacted by this. I still can't wrap my head around how this is legal or sustainable. If I buy $1MM of plant and equipment, I may not be able to expense it all in year 1, but I can relatively easily get a loan to finance the purchase of such--and manage my cashflows. The same is not for devs. I cannot easily get a loan for $1MM in dev salaries. In my own case, I don't need the loan to pay the salaries. I need the loan to pay the taxes for the portion of the salaries I cannot deduct as an expense. It's just insane.
A lot of people don't know what this Section 174 is about, so here's a brief explainer.
Normally, when you have expenses, you deduct them off your revenue to find your taxable profit. If you have $1 million in sales, and $900k in costs, you have $100k in profit, and the government taxes you on that profit.
Section 174 says you can't do this for software engineers. If you pay a software engineer, that's not "really" an "expense", regardless of the fact that you paid them.
What you've actually done, Congress said, is bought a capital good, like a machine. And for calculating tax owed, you have to depreciate that over several years (5 in this case).
Depreciating means that if you pay an engineer $200k in a year, in tax-world you only had $40k of real expense that year, even though you paid them $200k.
So the effect is that it makes engineers much more expensive, because normally when a company hires an engineer, like they spend on any other expense, they can at least think "well, they will reduce our profit, which reduces our tax obligation," but in this case software engineers are special and aren't deductible in the same way.
In the case of the $200k engineer, you deduct the first $40k in the first year, then you can expense another $40k from that first year in the second year, the third $40k in the third year, and so on through the fifth year. So eventually you get to expense the entire first year of the engineer's pay, but only after five years.
The effect is that companies wind up using their scarce capital to loan the federal government money for five years, and so engineers become a heavy financial burden. If a company hires too many engineers, they will owe the federal government income tax even in years in which they were unprofitable.
These rules, by the way, don't apply to other personnel costs. If you hire an HR person or a corporate executive, you expense them in the year you paid them. It's a special rule for software engineers.
It was passed by Congress during the first Trump administration in order to offset the costs of other corporate tax rate cuts, due to budgeting rules.
For folks that don't know the background on this, here's a layperson summary:
- A business is usually taxed on its profits: you deduct your revenue from the cost of producing that revenue, and the delta is what you are taxed on.
- In software businesses, this usually means if you spend $1M in software development to develop a web app, and it makes $1.1M in that year, you'd get taxed on the $100K profits.
- However, a few years ago, the IRS stopped allowing the $1M to be deducted in the year it was incurred. Instead, the $1M was to be amortized over 5 years, so now the business can only count $200K as the deductible expense for that year. So now it's going to be taxed on "profits" of $900K. Assuming the tax rate is 20%, that means the business owes $180K in taxes, even though it has a total of $100K in the bank after the actual expenses were paid. So it would have to either borrow to pay taxes or raise venture capital, meaning that VC-funded companies would be advantaged over bootstrapped ones!
- The letter's goal is to bring things back to how they were (and how they are for all other businesses): let businesses deduct their actual expenses from their actual revenue, and tax that actual profit.
I am neither a lawyer nor an accountant, this is just my understanding of this issue.
Edit: Switched the tax rate to 20%. The logic is still the same.
Signed. As a US-based developer, I fully support restoring the deductibility of software development expenses. This policy change quietly gutted countless startups and engineering teams—it’s long past time we fix it.
Appreciate YC and folks like @itsluther pushing this forward. This isn’t just a tax issue—it’s about keeping innovation and talent thriving in the US. Let’s get it done.
This US tax code change directly impacted my small business in a very real way that was directly felt by my household. In the past, it was a big boon for us and helped me afford to pay for some open source work and experimental things that helped our customers in the long run. Now we are back to mostly doing work-for-hire consulting. Even the experimental work I am doing, I am just paying for it and writing it off as typical business expenses. I cannot afford to take the credit because that means no deduction for this year. I don't have the cash in this small business context.
Thank you for helping to tackle this. The silence on this issue for the past few years from smaller software companies and their affiliates was surprising to me. The recent "time bomb" article was one of the few media pieces that actually took the time to describe it as anything other than a "tax cut for huge tech companies", which was refreshing.
My current favorite theory as to why there hasn't been more of an outcry is that many companies ignored the rule change (either out of ignorance or as an alternative to going out of business), and are forced to remain silent.
I seem to remember people being broadly in favor of this change at the time it was first proposed because it would elevade software development and create more long-term stability, but in a world where the primary focus is on quarterly funding rounded and acquisitions it obviously skews the numbers and thus the potential founded/early investor upside.
There are two possible motivations for the impending change. One is the argument that deducting 100% of developer labor isn't ideal because developers create IP whose value can compound as an asset, rather than the labor being 'consumed' in production as with manufacturing (where any long-term benefit after the initial sale goes to the consumer). The other is that it's a legislative stick designed to herd a powerful investor/donor lobby into supporting budget legislation in exchange for turning the favorable tax treatment faucet back on.
Possibly dumb question...
For a medium/large company, is this really a big deal? Their payroll is relatively stable year-over-year, so after a few years, it all evens out (very roughly). Or am I missing something?
IE, is this really an anti-competition law, designed to protect entrenched tech industry players and prevent up-starts from, well, starting?
I'm all for it, just curious as the law has existed for 8 years and been in effect for 3. Seemingly little interest from anyone in the tech world to put lobbying behind reversing it until this point.
@dang (and others). If you want a groundswell of support have you consider have you considered reaching out to game devs and indie game devs? It seems like they'd all be negatively affected. They'd spread the word to players.
I ask simply "If I have $1m of revenue and $1m of expenses that is entirely software dev salaries, what do you think my profit is for that year? How much should I be taxed on that?"
If you work at all in energy, the Clean Energy Business Network is also proactive in fighting for change. A couple of years ago they put me touch with Ron Wyden's staff. The Democrats are almost universally opposed to what was added to Section 174.
I think people are missing the actual process used by Finance teams relating to this issue. I am a former CFO and spent a fair amount of time with this issue in my last role. The firm had a significant amount of software engineering expense related to its core operating system that was the backbone of the company.
The FASB accounting rules drive the capitalization of software expenses, not the tax rules. The FASB definition of GAAP (Generally Accepted Accounting Principals) for US firms is very specific and requires significant detailed tracking to comply.
As noted in one of the other posts, many companies want to capitalize as much software engineering expense as possible as that leads to higher operating income and net income. Bonuses, option grants and stock prices tend to be tied to those metrics. The argument is that building a piece of software should be treated like purchasing it off the shelf. If a firm pays $1M to implement SAP, it does not have to expense it all in one year, but rather depreciates it over its “expected life.” Since “expected life” is difficult to define for every piece of software, there are default lifetimes (similar to saying motor vehicles default to a 5 year depreciation schedule).
Tax then generally follows the GAAP accounting except when the government intervenes to try and increase capital spending. Periodically the government will allow accelerated depreciation which increases operating expenses for tax purposes only which reduces current period cash taxes. Note total taxes do not change, only when they get paid.
The Section 174 under discussion here is simply the same idea then applied to software development in an effort to juice hiring.
For the people discussing whether the IRS is effectively tracking and enforcing this - the IRS really does not matter. A companies auditors enforce it. Without all of the necessary paperwork/digital audit trail, a firm in not permitted by the auditors to capitalize the expense. The same auditors have to sign off on the tax treatment as well.
Finally, with respect to maintenance, the idea is meant to be similar to the treatment for machinery ( i.e. traditional capital expenditures). When a firm puts gas in the company truck or replaces tires or fixes a windshield, they do not capitalize those expenses. The idea is the expense do not fundamentally improve the item or meaningful extend the life beyond the initial expectations. Following that line of thought, maintenance releases are not thought to extend the life of the software while significant improvements to the software do and therefore can be capitalized.
DISCLAIMER - while I was a CFO, I was not a Certified Accountant. What I have described above is what the accountants and my audit firms described to me as I worked through this issue in preparing financial statements.
Japan has required amortization of capitalized software over five years for qualifying internal-use software since at least 2000. Correct me if I’m wrong, but I believe most other countries have similar rules.
Until 2022, U.S. companies had a real competitive advantage.
Software developer salaries in Japan are depressed—other roles too, but especially engineers. Without digging too deep, perhaps the previously unfavorable (now roughly equal) tax treatment of was perhaps a contributing factor.
I'm writing to express my urgent concern regarding the negative impact of the 2022 Section 174 tax code changes on small businesses like mine. As owner of Rietta, Inc., a small cybersecurity firm, I still do much of the technical work. My wife and I have three young children under 6. My family and I have been directly negatively impacted by these changes from the 2017 act.
Previously, the tax code helped us afford open-source and experimental work that benefited customers. For example, modernizing applications to run on Docker improved testing and deployment. Our State government clients now benefit, but this was once experimental. Now we're largely back to just work-for-hire consulting, treated as cost of goods sold. I don't have the cash to pay for experimental software development only to then amortize it over five years. If I have $100k revenue and spend $100k, the current code allows only a $20k deduction. I owe taxes on the other $80k despite no cash or documented asset value. Experimental software doesn't work like that in this field.
I started this business 26 years ago. We provide important long-term custom programming and update work for private sector and State government clients ("STATE A" and "STATE B" judicial branches). Often, we work with code we didn't originally write.
As a professional computer scientist and business owner, I rely on my CPA for tax compliance. If I've erred in my example, that's on me. But I can tell you this amortization requirement particularly cripples small businesses like Rietta, Inc., where cash flow is critical, severely limiting the quality of services I can afford to provide.
I support undoing this tax change.
I would be surprised if nearly all software companies wouldn't consider their code to be a valuable capital asset. For example, do you think your company would be okay with releasing commits/snapshots of their source code and design docs into the public domain once they hit 5 years old? Or do they currently depreciate too quickly?
That's a great explanation, thanks a lot for sharing it.
Some big tech companies affected have laid off teams around the world, perhaps in order to mitigate the numbers looking bad to investors; so in a way, this adversely affected tech employees globally.
Every country should have such a rule for software businesses, which is an industry where all the cost has to be upfronted, so that bootstrapping is facilitated. There are plenty of smaller markets where the VC model is not
the most appropriate funding instrument.
While this does convey the idea, the premise is also biased.
> even though it has a total of $100K in the bank after the actual expenses were paid.
People running a business can perfectly understand the concept of liquidity. And yes, just because you transform money to something else, then it doesn't mean that you should not be taxed on it.
The extreme example is a company that buys gold on the last trading day of the year - now there is no profit! On the first day they sell the gold again and does tax eviction.
The core question is to what extend software constitutes an asset or consumption.
(Personally, I do not believe that software constitutes an asset in any meaningful way, but a practical tradeoff could be that software is a 10% asset)
AFAICT, that $450K is refundable and transferable. IOW, if you make $0 in year two and have expenses of $0 in year two, you'd get a tax refund of $100K because $200K of your expenses from year one would be applied to year 2.
And it's transferable -- if your company fails, there are companies out there that will buy the rump of your company to realize the unrealized tax refunds.
Which is why it's usually fairly straightforward to get a factor loan to pay those $450K in taxes -- it's backed by an asset.
Factor loans are usually expensive with a high interest rate. Because you can get a factor loan, the taxes are not going to immediately bankrupt the company in the short term, but the high interest rates are going to hurt in the long term.
Not a lawyer nor an accountant. Not even an American.
That's nuts, since a payroll should never be considered an asset. That's trying to put a material value on software, and doing it based on the salaries of developers is as crazy as valuing it in lines of code.
The value of software could be based on something more realistic, like a percentage of actual revenue, but I suppose tech giants would be against that.
So it applies to software engineers but under what definition of software engineer?
This [1] is the only definition the code actually give.
> (3) Software development
> For purposes of this section, any amount paid or incurred in connection with the development of any software shall be treated as a research or experimental expenditure.
Is a test or QA engineer considered a software engineer?
Is an FPGA or ASIC engineer still considered a software engineer if they are writing in HDLs?
Is a systems engineer, electrical engineer, or mechanical engineer considered a software engineer because they use MATLAB, etc and use programming to do their design work?
Is a sysadmin, DB admin, or other IT staff considered a software engineer because they write software as part of their job?
What about a quantitative analyst, data scientist, accountant, actuary, or any of the other maths and analysis adjacent job roles that regularly use some level of programming to do their job (and therefore write software)?
What about HR, etc who use excel documents? Excel is fundamentally just a graphical array programming language (and the design of spreadsheet tools is heavily inspired directly from APL). Is anyone who uses excel or builds/maintains spreadsheets considered a software engineer?
Like software engineering is such a broad field and programming bleeds into every part of modern business at this point.
It's not amortized. I.e. the company simply subtracts all salaries for the year from the revenue and pays tax from the difference. Salaries being amortized means on year 1 you can only subtract X% of salaries and the taxable amount becomes much larger. Year 2 you will use the X% for the second year salary and another Y% for the already paid salary of the first year. So, the difference becomes less, and the taxes become less, too.
For a stable company that has a constant revenue stream and an established body of workers there's no much of a difference: instead of paying all tax for current year salary you pay 6 chunks of tax for 6 different years of salaries - which would be about the same amount.
For early companies things can be pretty tough. You may earn, say 100k in a year one and pay your employee 100k. Your company now has 0 in the bank, but for the taxation purposes the taxable amount is like (100k - 10% of 100k = 90k), at 20% corporate tax that would mean that the company has 0 in the bank but owes the government $18k in taxes. It's much harder to start a software business in this kind of environment.
Forgive the naive question, but is this different than other payrolled employees? So for normal employees you get the deduct the year it's paid, but for some reason for software developers you have to amortize it?
Ok, say I call. What do I say: "Hey I want to show my support for the Big Beautiful Bill because it reverses the tax deduction for software engineers."
And then what? (asking honestly lol for anyone who's done this before)
Lobbying has been ongoing since the law was enacted. Congress came close to repealing it several times, with the House actually passing a bill to repeal it (Tax Relief for American Families and Workers Act of 2024).
Just because Hacker News doesn't care doesn't mean it hasn't been a big focus of small business lobbying since before it came into effect.
The actual reason it hasn't been repealed is politics: It makes the CBO budget deficit look much worse. It seems as though neither party wants the optics.
I don't recall there being favorable reception when Trump's Congress passed it nor since. At best, non-awareness, and 'cost of business' for whatever the other talking points at the time.
You can see the older HN threads, people were shocked, and it comes up perennially, with calls to restore favorable tax treatment that incentivizes vs punishes business growth. Same pattern in social media responses to news articles.
> Other kinds of messages take longer.
Emails have to be manually read and sorted.
Faxes have to be digitized and emailed. [...]
By contrast, congressional staffers tally phone calls right away.
Golly. Is this a problem? Hasn't this been solved already? Do they want to solve it? How much do they want to solve it, in terms of United States Dollars?
This is now easy for many HNers to build, with the hard parts now done by free off-the-shelf components.
The customer could have those email tallies even faster than the phone staffer tallies, for the timely read on constituents that the 5calls.org Web page suggests.
And then they can manually or semi-manually review the emails later, for nuance and genuine responses. But they got the important tallies immediately, on their live dashboard and timely alerts.
(But keep those human staffers answering phone calls, since I'd guess that AI on phone there would alienate the very engaged voters who still make phone calls.)
In Sweden you have the option to capitalize software development costs, under some specific circumstances, but in general you would expense such costs immediately.
Some startups do it to window-dress their balance sheet, though. But making it compulsory is absurd.
How does that even work? You’re saying many companies committed tax fraud by ignoring the law change and continued to deduct software developer salaries as they had in the past?
Many larger companies have an incentive to attribute layoffs to AI, because that serves to hype their AI products. Basically, they didn't want to say, "we are laying people off for financial reasons." Even though the financial reasons were triggered by a change to the tax code, because that doesn't play well in the media, particularly during a period of elevated profits. So Google, Microsoft, etc. laid a bunch of engineers off to reduce their tax burden and used AI as an excuse.
I keep seeing an objection in this thread along the lines of "what make software so special that it deserves a tax deduction".
Correct me if I'm wrong, but if a company hires someone to say, mine coal or brew beer, the expense of those employees is an expense any company can claim a full tax deduction on. If you're a line chef or wait tables, your salary is tax deductible to the restaurant.
So it's not that we are asking for R&D to be treated "specially" and get a deduction that other companies don't have. The problem is that R&D salary expense is being singled out as producing an asset (e.g. IP), and thus being classified in the same category as other assets, like, brewing equipment, a mining excavator, or a pizza oven. Simply put, Section 174 argues to classify people in the same category as things because ... 'these people's work outputs may have long-term value, kind of like things'(?).
Allowing Sec 174 to stand is a slippery slope to classifying more and more everyday Americans' salaries into this category. One could argue in the future, for example, that those who design cars or operate machines to produce tooling dies, should not have their labor treated as regular expenses, but instead as capital assets because their labor output is captured in assets, just as Sec 174 treats the labor of software developers as assets. Everyday people should be concerned by this because if the rule stands, it could be extended to you, too.
For those objecting to the equal treatment of R&D employees as all other employees in America of all stripes and vocations, keep in mind that software people have to pay personal taxes on the income, just like everyone else. Section 174 doesn't have anything to do with personal income taxes: we all pay income taxes fair and square. The question is whether there is a double-tax on software labor, paid at the corporate level (and in all likelihood, your salary is currently a tax deduction for your company, unless you write software or do R&D).
I think the assumption that we are asking for "special treatment" is driving some confusion and grass-roots objection to the movement here, so I wanted to highlight that we are just asking for everyday people who work software and other R&D jobs to be treated just like every other American who works a day job.
At this point, does this really affect many people? Most businesses should be well on their way to the expenses normalizing. Outside of new businesses and old businesses splurging, would this really accomplish much?
This is the first instance I’ve heard of where salaries aren’t considered remuneration for basic labour. It’s a fairly weird interpretation of reality that spending $200k on a human’s availability results in a guaranteed $200k of capital being created, regardless of which country this kind of tax law exists in.
Dev here working in Japan for few years, I don't think the main reason software salaries are low in Japan is financial, but social/cultural. Software has traditionally not seen as valued as hardware, it was just an "extra" added on top of the hardware part. Basically never went through the startup revolution of the 2000s in US.
Also Japan is still very hierarchical, so old ideas change much slower. I would say the combination of these 2 are the main reason software is not as valued as in e.g. America, but there are many others like lack of international competitiveness due to the low English skill, ZIRP, and the ones you note seem totally valid ofc.
This is a very interesting recent report about salaries in Japan (e.g. foreigners, and/or foreigner companies get paid/pay a lot more):
Content explicitly advocates for and enables freedom of expression: invites community to 'sign this letter' to lawmakers, frames petition as mechanism for 'add our voices,' acknowledges that disagreement exists and positions diverse views as valuable input to democratic process
FW Ratio: 50%
Observable Facts
Post explicitly states 'please sign this letter to the relevant committee members' and describes signing as a way to 'contribute to getting this done'
Post says 'not everyone here agrees with us—HN is a big community, there's no total agreement on anything—but this issue has as close to a community consensus as HN gets, so I think it makes sense to add our voices too'
Inferences
The explicit invitation to petition government and deliberate framing of letter-signing as expression ('add our voices') directly exemplify Article 19 freedom to hold and express opinion
Acknowledging disagreement and positioning diverse views as legitimate contributions demonstrates respect for pluralism in exercising expressive rights
Content explicitly enables political participation: invites US taxpayers to sign petition to 'relevant committee members,' directly engages citizens in legislative process, frames petition as mechanism for democratic voice ('urge lawmakers')
FW Ratio: 50%
Observable Facts
Post provides direct link to letter-signing form and states 'sign this letter to the relevant committee members'
Post explicitly instructs '(If you're not a US person, please don't sign the letter, since lawmakers will only listen to feedback from taxpayers)' respecting geographic scope of political participation
Inferences
Providing a concrete mechanism for citizens to directly petition government representatives exemplifies Article 21 right to participate in governance
The geographic boundary (US taxpayers only) demonstrates respect for legitimate state jurisdiction in representative democracy rather than negating the participatory right
Content describes organizing collective action: 'Luther has been organizing YC alumni to urge lawmakers' and 'I asked him if we could do that on Hacker News too.' Frames participation as collective ('add our voices') and grassroots
FW Ratio: 50%
Observable Facts
Post states 'Luther has been organizing YC alumni to urge lawmakers to support this reversal' and 'I asked him if we could do that on Hacker News too'
Post refers to the effort as 'our voices' and 'we can contribute' indicating collective participation
Inferences
The explicit framing of organizing community members to act collectively directly supports Article 20 freedom of peaceful assembly and association
The grassroots, community-initiated structure (asking permission to organize within HN rather than imposed directive) respects autonomy in association
Content discusses collective community action around shared concern; invokes principles of community consensus and cooperative problem-solving aligned with Preamble values of equal rights and cooperation
FW Ratio: 50%
Observable Facts
Post describes 'organizing YC alumni to urge lawmakers' and extending this to 'Hacker News' community to 'add our voices too'
Post acknowledges that 'not everyone here agrees with us—HN is a big community, there's no total agreement on anything' while still framing participation as valuable
Inferences
The emphasis on community consensus and collective action reflects Preamble ideals of equal participation and mutual commitment to rights protection
Acknowledging disagreement while inviting participation demonstrates respect for the diverse voices within a rights-bearing community
Content discusses tax deductions for 'software dev expenses,' which relates to labor compensation and working conditions; however, content frames issue from business perspective (cost impacts on companies) rather than worker welfare perspective
FW Ratio: 50%
Observable Facts
Post states 'Companies building software in the US were hit hard a few years ago when the tax code stopped allowing deduction of software dev expenses' and 'they have to be amortized over several years'
Tax policy changes affect business profitability, which indirectly affects employee compensation and working conditions
Inferences
While the policy relates to labor economics and worker compensation, the framing prioritizes business interests over explicit worker welfare concerns
The tangential connection to Article 23 is through economic impact on working conditions rather than direct engagement with labor rights or fair wages
Content tangentially relates to benefits of scientific and cultural progress; supporting software development through favorable tax policy indirectly enables technological progress
FW Ratio: 50%
Observable Facts
Post centers on incentivizing software development as economically valuable activity, implicitly recognizing technological progress as beneficial
Inferences
Supporting conditions for software development (via restored tax deductions) indirectly relates to enabling scientific and technological advancement
Equal protection and non-discrimination before law not explicitly engaged; tax policy described as universal but not analyzed for equality of treatment
Post provides concrete tool (Google Form URL) and clear mechanism for participating in democratic process; respects jurisdictional boundaries by restricting to US taxpayers
Post structure provides direct mechanism (linked Google Form) for readers to exercise expressive rights; respects individual choice to participate or decline
Post structure enables community assembly through voluntary participation in organized effort; grassroots mobilization is bottom-up and community-driven rather than top-down imposed
Equal protection and non-discrimination before law not explicitly engaged; tax policy described as universal but not analyzed for equality of treatment
Content discusses tax deductions for 'software dev expenses,' which relates to labor compensation and working conditions; however, content frames issue from business perspective (cost impacts on companies) rather than worker welfare perspective
Content tangentially relates to benefits of scientific and cultural progress; supporting software development through favorable tax policy indirectly enables technological progress
Post claims 'this issue has as close to a community consensus as HN gets' to justify why HN should join the effort, implying that popular agreement legitimizes action