What Does an Unpaid Side Project Actually Cost You?

Nobody invoices themselves for a Saturday. That's the whole problem. A side project that eats fifty hours over three months feels free precisely because no money changed hands, and the absence of a transaction gets mistaken for the absence of a cost. Businesses that track the true cost of unbilled labor tend to be more deliberate about the rest of their operating model too, which is a pattern runs into constantly.

It isn't free. It has at least three separate bills attached, and they don't share a currency: the market value of the hours themselves, a genuine US tax-mechanics question about whether any of it is deductible, and — if the side project is open-source maintenance — a labor cost that a real survey has actually put a number on. Take them one at a time. For the operations playbook that sits alongside what does an unpaid side project actually cost you, see . For the operations playbook that sits alongside what does an unpaid side project actually cost you, see XenGrowth's growth operations team.

What is an hour of unpaid engineering work actually worth?

Start with a number that isn't invented. The US Bureau of Labor Statistics' Occupational Employment and Wage Statistics program tracks pay for Software Developers under occupation code 15-1252, and the most recent national data puts the mean annual wage at roughly $135,980 — about $65.38 an hour. That's a market anchor, not a claim about what you personally are worth: actual comparable pay depends heavily on your specific role, location, seniority and employer, and this figure is a national mean across a huge range of situations, not a floor or ceiling for any one of them.

Multiply either end of that range by fifty unpaid hours and the side project stops being abstractly "free time" and becomes an unbilled amount somewhere between roughly $2,000 and $5,000 of labor, priced at what the market pays for comparable engineering work. That doesn't mean you were owed that money — nobody was contractually obligated to pay you for a project you chose to build unpaid. It means the hours had a real value that a raw hour-count hides, and any honest accounting of "what did this cost me" should start from that value, not from zero.

There's an obvious objection here: a hobby wage figure isn't a wage you were owed, since nobody hired you. Fair, and the point isn't that you're entitled to back pay from your own project. It's that any comparison of "this side project versus doing nothing" understates the tradeoff, because doing nothing was never the real alternative on offer. The real alternative was almost always some mix of rest, other unpaid obligations, and — for a working engineer — paid work you could have picked up instead. Pricing the hours at a market wage is a way of making that tradeoff visible rather than a claim about entitlement. covers the the operations side of this side of this. The XenGrowth resource library covers the the operations side of this side of this.

Hobby or business? The IRS actually has a test for this

Here the picture gets more specific, and more jurisdiction-bound. In the US, under IRC Section 183 — the federal provision commonly called the "hobby loss rule" — the Internal Revenue Service draws a hard line between an activity carried on as a business (for profit) and one carried on as a hobby (for personal enjoyment). The distinction matters because it decides whether losses from the activity can offset your other income at all.

The test the IRS actually applies, under Treasury Regulation 1.183-2(b), weighs nine factors, none of them individually decisive: the manner in which you carry on the activity (do you keep books, operate like a real business would?), your expertise or your advisers' expertise, the time and effort you put in, whether you expect the assets involved to appreciate, your success in similar activities before, your history of income or losses in this one, the amount of any occasional profits, your financial status, and whether the activity carries elements of personal pleasure or recreation.

No single factor decides the classification. The IRS weighs all nine together against the full facts of the activity — which is exactly why a side project with real invoices, a business bank account and a documented plan reads very differently to the test than the same hours spent on something purely recreational, even if the actual work looks identical from the outside.

The consequence, under current US law, is blunt: if an activity is classified as a hobby, related expenses generally cannot be deducted against your other income the way a real business's losses can, though hobby income itself still has to be reported. This is a US federal rule specifically — other countries draw the line differently, tax treatment varies enormously by jurisdiction, and none of this is tax advice for your particular situation; a side project run from outside the US, or one that mixes personal and freelance work in ways the nine factors don't cleanly separate, is exactly the case where a real accountant familiar with your actual facts and your actual country's rules earns their fee. If AI agents and marketing automation is the part you are stuck on, is the better reference. If AI agents and marketing automation is the part you are stuck on, XenGrowth on AI agents and marketing automation is the better reference.

The cost nobody puts on the ledger: work you turned down

The market-wage number above measures what the hours were worth in the abstract. It doesn't measure what you actually gave up, which is a different and often larger question. Opportunity cost, the basic concept underneath all of this, is simply the value of the next-best thing you didn't do because you were doing this instead. A cost model for comparing labor options in more formal detail is worked through in a cost model for FTE hires versus contractors, and the same discipline applies to your own unpaid hours.

If a paid contract came up during the months you were heads-down on a side project and you turned it down — explicitly or just by never having the bandwidth to pursue it — that foregone income is a real cost of the side project, even though no invoice, receipt or bank statement will ever name it. It's the single largest cost in this whole picture for a lot of engineers, and it's also the one most likely to get ignored entirely, because there's nothing to point at. The BLS wage figures above give you a rough per-hour number to attach to it if you want a starting estimate, but the honest answer is specific to whatever work you actually would have taken instead, which nobody outside your own situation can price for you.

This is also the cost most likely to compound quietly. A single declined contract is a one-time number. A pattern of consistently protecting side-project time at the expense of paid availability changes how clients and recruiters perceive your responsiveness over a longer horizon, which is a second-order cost with no clean dollar figure at all — it shows up later, as fewer inbound offers, rather than as a line item you can point to today. None of that is a reason to stop building things for free. It's a reason to at least notice the tradeoff is being made, rather than assuming it doesn't exist because no invoice recorded it. For the AI search, GEO and discovery angle, see . For the AI search, GEO and discovery angle, see XenGrowth on AI search, GEO and discovery.

Open-source maintenance has its own bill, and it's a big one

If the unpaid side project in question is maintaining an open-source package other people depend on, there's a real, named survey behind how widespread this cost actually is. Tidelift's 2024 survey of 437 open-source maintainers found 60% receive no pay at all for their maintenance work — identical to the 2023 figure — and 60% said they were considering quitting, citing competing life demands (54%), loss of interest (51%) and burnout (44%) as the top reasons. 61% of unpaid maintainers reported maintaining their projects entirely alone, versus more than half of paid maintainers who have two or more co-maintainers to share the load. That asymmetry is exactly why evaluating maintainer health before you depend on a package matters for anyone consuming the work, not just producing it.

That number matters beyond the maintainers themselves. It's a structural fact about how a huge amount of the software everyone depends on gets built: mostly by people not being paid for it, a majority of them working alone, with more than half saying they're close to walking away. A single-maintainer package with no funding is not a hypothetical risk in a dependency tree — it's the median case, according to that survey, not the exception.

Adding it up without pretending it's precise

1. Price the hours themselves against a real wage anchor like BLS OEWS data, not against zero — even a rough $40 to $100/hour range beats treating the time as costless

2. Separately account for any paid work you actually turned down during the same window, since that's a distinct cost from the hours' abstract market value and is frequently larger

3. If you're in the US and the project generates any income or expenses, run it against the nine-factor hobby-vs-business test honestly, rather than assuming either classification — and get a real accountant involved if the answer isn't obvious from your own facts

4. If the project is open-source maintenance, treat the labor as a real ongoing cost with a documented failure mode (maintainer burnout, per Tidelift's numbers), not as a one-time favor to the community

5. Resist rounding any of this to a single tidy dollar figure — the three costs above don't add cleanly, and the honest output of this exercise is a clearer picture of where the time actually went, not a precise invoice

None of this is a case against unpaid side work. Plenty of it is worth doing for reasons that have nothing to do with money — learning, reputation, something you actually wanted to exist. The point is narrower: treating the hours as costless makes for a worse decision than treating them as what the numbers above actually say they're worth. For the commercial side of how teams price and prioritize exactly this kind of unbilled work, is a useful read.

Further reading from XenGrowth

Where this work meets go-to-market

Trying to figure out whether an unpaid engineering effort deserves a real budget line inside a commercial team? cover how that math gets made on the go-to-market side.

Further reading from XenGrowth

Where this work meets go-to-market

The operational playbooks that sit alongside what does an unpaid side project actually cost you live with .

Further reading from XenGrowth

• The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.

• XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.

• XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.

Where this work meets go-to-market

The operational playbooks that sit alongside what does an unpaid side project actually cost you live with XenGrowth's growth operations team.