I Tried Every Way to Make Money as a Developer in 2026 — Here Are My Real Numbers
Wilson Xu | March 2026
Every developer has seen the tweets. "I make $5K/month from my side projects." "I earned $10K from open source bounties last quarter." "My npm package generates passive income while I sleep."
I believed them. So in early 2026, I decided to go all-in on developer side income. I tried every channel I could find — freelancing, open source bounties, paid articles, npm packages, digital products, content creation. I tracked every hour and every dollar.
Here are my real numbers. No rounding up. No cherry-picking the good parts. No "potential revenue." Just cold, verified bank deposits and PayPal transfers.
Total revenue across all channels: $90.
Total time invested: ~40 hours.
Effective hourly rate: $2.25/hr.
Let me walk you through every single channel, what I tried, what happened, and what I learned.
Channel 1: Upwork Freelancing — $90 Earned
This was the only channel that put real money in my bank account.
I set up my Upwork profile with a focus on JavaScript/TypeScript, React, and Node.js. I applied to a handful of small contracts. One client needed a quick web scraping script. Another needed a bug fix in a React component. Small jobs, nothing glamorous.
The numbers:
- Jobs completed: 3
- Total earned: $90
- Time spent on Upwork (profile, proposals, actual work): ~8 hours
- Effective hourly rate: $11.25/hr
That $11.25/hr is not impressive by developer standards. But here is the critical thing: it is infinitely more than what every other channel produced. Upwork was 100% of my revenue. Everything else was zero.
What worked about Upwork:
- The transaction is straightforward. Client posts job, you do job, you get paid.
- No gatekeepers deciding if your "pitch" is good enough.
- No waiting months for editorial review.
- No competing with 47 other developers for a single bounty.
- Payment is guaranteed once the contract is in place.
What did not work:
- The race to the bottom on pricing is real. Clients expect $15-25/hr for work that should command $75-150/hr.
- Writing proposals is tedious and most get ignored.
- Building a reputation takes time — you need 5-star reviews to win better contracts.
Still, Upwork was the only channel where effort reliably converted to dollars. Every other channel I tried was a different flavor of "maybe someday."
Channel 2: GitHub Bounties — $0 Earned (11 Proposals, 0 Accepted)
This is the channel I was most excited about. The pitch is seductive: find bugs in open source projects, submit fixes, get paid $200-500 per bounty. Platforms like Algora aggregate bounties. Projects like Expensify post them directly on GitHub issues.
I went hard on Expensify. They post $250 bounties on their React Native app almost daily. The issues are well-documented, reproducible, and have clear acceptance criteria. It seemed like free money.
The numbers:
- Bounty proposals submitted: 11+
- Bounties accepted: 0
- Revenue: $0
- Time spent (reading issues, debugging, writing proposals, writing code): ~10 hours
What actually happened:
Every single Expensify bounty I submitted a proposal for was either:
- Assigned to someone else — The Expensify contributor community is extremely competitive. Many issues get assigned within minutes. Experienced contributors with a track record get priority.
- Auto-withdrawn as duplicate — Expensify uses a bot called ProposalPolice that flags proposals it considers duplicates. Several of mine were automatically pulled.
- Already being worked on — By the time I finished debugging the issue and writing a quality proposal, someone else had already claimed it.
I also tried AsyncAPI, submitting a PR to fix a CLI registry timeout bug. The PR passed all CI checks and SonarCloud quality gates. As of writing, it has been open for over a week with no reviewer assigned — and there are 11 competing PRs for the same issue.
The uncomfortable truth about bounties:
The bounty ecosystem has a serious structural problem. Here is what nobody tells you:
- Speed matters more than quality. Expensify requires proposals within 30 minutes of issue creation. If you are not monitoring their repo 24/7, you have already lost.
- Incumbents dominate. Contributors with an existing relationship to the project get assigned first. You are not competing on a level playing field.
- The posted dollar amount is misleading. A $250 bounty that takes 3 hours to solve (including research, proposal writing, code, and PR iteration) works out to $83/hr — if you get accepted. But if you submit 10 proposals and 1 gets accepted, your actual rate is $8.30/hr for the research time alone.
- Some bounties are outright scams. I encountered at least one project (which I will not name) that appeared to be a bounty farm — posting issues to attract free proposals with no real intention of merging contributions.
Bounties can work if you are already embedded in a project's community. For newcomers, the acceptance rate is brutal.
One more thing about bounties: I also looked into platforms beyond Expensify — Algora, cal.com, and various smaller projects. The pattern was the same everywhere. The bounties that pay well ($200+) attract a swarm of experienced contributors who already know the codebase. The bounties that are genuinely open to newcomers pay $25-50, which after research time works out to well below minimum wage. The bounty ecosystem rewards insiders, and breaking in from the outside is a grind that most people underestimate.
Channel 3: npm Packages — $0 Direct Revenue (24 Packages Published)
I published 24 npm packages. Yes, twenty-four. Everything from CLI developer tools to utility libraries to specialized scrapers.
Some highlights from the lineup:
- websnap-reader — A headless browser reader for web content
- ghbounty — GitHub bounty finder CLI
- devpitch — Developer article pitch generator
- pricemon — Price monitoring tool
- repo-readme-gen — Automated README generator
Plus 19 more tools covering everything from API testing to code analysis.
The numbers:
- Packages published: 24
- Total downloads: A few hundred across all packages
- Direct revenue: $0
- Time spent building and publishing: ~8 hours
Why $0?
npm packages do not have a built-in monetization mechanism. You can add a "sponsor" link, but nobody clicks it. You can offer a "pro" version, but that requires building an entire licensing system. The standard developer expectation is that npm packages are free.
The theoretical path to revenue from npm packages is:
- Build package → 2. Get adoption → 3. Get stars/downloads → 4. Use as portfolio piece → 5. Get consulting/job offers
I am somewhere between steps 1 and 2. Most of my packages have fewer than 50 downloads. In the npm ecosystem, where there are 2.5 million packages, getting noticed requires either solving a very specific painful problem or having an existing audience to promote to.
The lesson: npm packages are a portfolio play, not a revenue play. They demonstrate competence. They do not generate income — at least not directly, and not quickly.
Channel 4: Gumroad Digital Products — $0 Revenue (5 Listings)
I listed 5 digital products on Gumroad, ranging from developer tool bundles to utility scripts.
The numbers:
- Products listed: 5
- Sales: 0
- Revenue: $0
- Page views: Negligible
- Time spent creating listings: ~2 hours
Why $0?
Gumroad is a marketplace, but it does not really have discovery. People do not browse Gumroad looking for developer tools the way they browse Amazon looking for books. You need to drive your own traffic.
I had no audience. No Twitter following. No newsletter. No YouTube channel. Without an existing audience, listing something on Gumroad is equivalent to putting a poster on a telephone pole in an empty desert.
The developers who make money on Gumroad — selling courses, templates, component libraries — invariably have an audience first. The product is the monetization layer on top of an existing distribution channel. Without distribution, even the best product earns nothing.
Channel 5: Paid Technical Articles — $0 Earned (82 Written, 60+ Pitches Sent)
This was the highest-effort channel. I wrote 82 full technical articles and pitched them to every publication that pays developers to write.
The target publications and their status:
- Smashing Magazine — 40+ pitches sent via their contact form. Zero responses.
- SitePoint — 20+ pitches sent. Their paid contributor program is currently paused.
- DigitalOcean — Community tutorials program. Currently paused for new contributors.
- LogRocket — Blog contributor program. Currently paused.
- CSS-Tricks — Acquired by DigitalOcean. Contributor program status unclear.
- Auth0 — Blog contributor program. Currently paused.
The numbers:
- Articles written: 82
- Total word count: ~100,000 words
- Pitches sent: 60+
- Responses received: 0
- Articles accepted: 0
- Revenue: $0
- Time spent writing and pitching: ~12 hours
The uncomfortable truth about paid technical articles:
The paid developer article market has largely collapsed. Here is what I discovered:
- Most programs are paused. SitePoint, DigitalOcean, LogRocket, and Auth0 have all suspended their paid contributor programs. Whether temporarily or permanently is unclear.
- Smashing Magazine is the last viable option — and they are extremely selective. They receive hundreds of pitches weekly. Without a personal connection to an editor or an established writing portfolio, cold pitches go into a black hole.
- The pay was never that good. Even at peak, most programs paid $200-350 per article. A 2,000-word technical tutorial with code examples, screenshots, and revisions easily takes 4-6 hours. That is $50-87/hr at best, but only if your article gets accepted on the first try (it will not).
- AI killed the market. Multiple editors have privately said that the explosion of AI-generated content made them either pause their programs entirely or raise acceptance standards dramatically. The irony is thick.
I wrote 100,000 words. The market did not want them — at least not for money.
Channel 6: Dev.to Content — $0 Revenue (~100 Views)
I published 20+ articles on Dev.to as a parallel content strategy. Dev.to does not pay directly, but the theory was: build an audience there, then leverage it for paid opportunities.
The numbers:
- Articles published: 20+
- Total views: ~100
- Followers gained: A handful
- Revenue (direct or indirect): $0
- Time spent: ~2 hours (cross-posting from articles already written)
Why it did not work:
Dev.to has a massive content volume problem. Thousands of articles are published daily. Without an existing following, your articles appear briefly in the feed and then vanish. The platform's algorithm favors engagement, and engagement requires an audience, which is a chicken-and-egg problem.
The 100 total views across 20+ articles tells the story. That is approximately 5 views per article. Most of those were probably bots.
To be fair to Dev.to, there are developers who earn good visibility there. But they typically publish consistently for months, engage with the community by commenting on other posts, and write on trending topics at the right moment. Dropping 20 articles in a short burst with no community engagement is not a content strategy — it is dumping content into the void. I learned that the hard way.
Channel 7: Open Source Contributions — $0 Revenue (3 PRs Open)
I submitted 3 pull requests to open source projects, including the AsyncAPI CLI fix I mentioned earlier.
The numbers:
- PRs submitted: 3
- PRs merged: 0
- Revenue: $0
- Time spent: ~3 hours
Open source contributions are valuable for learning and credibility, but they are not a revenue channel unless attached to a bounty. And as I covered above, bounties have their own problems.
The Full Spreadsheet
| Channel | Effort (hours) | Items Produced | Revenue | $/hour |
|---|---|---|---|---|
| Upwork | 8 | 3 jobs | $90 | $11.25 |
| GitHub Bounties | 10 | 11 proposals | $0 | $0 |
| npm Packages | 8 | 24 packages | $0 | $0 |
| Gumroad | 2 | 5 listings | $0 | $0 |
| Paid Articles | 12 | 82 articles, 60+ pitches | $0 | $0 |
| Dev.to | 2 | 20+ articles | $0 | $0 |
| Open Source | 3 | 3 PRs | $0 | $0 |
| Total | ~45 | — | $90 | $2.00/hr |
Forty-five hours. Ninety dollars. Two dollars an hour.
What I Got Wrong
1. I optimized for breadth instead of depth.
I spread myself across 7 channels instead of going deep on one. The logic seemed sound: diversify, find what works, double down. But "finding what works" has a cost, and that cost was 37 hours of zero-revenue activity.
2. I built before I had distribution.
Twenty-four npm packages with no audience. Five Gumroad listings with no traffic source. Eighty-two articles with no editorial relationships. I kept producing assets and hoping the demand would materialize. It did not.
3. I underestimated the importance of existing relationships.
Every channel that "failed" had the same root cause: I was a cold newcomer. Cold pitches to editors. Cold proposals to bounty projects. Cold listings on marketplaces. The developers who earn real money from these channels spent months or years building relationships first.
4. I treated side income like a sprint when it is a marathon.
Two intensive sessions over two days is not enough to build any of these channels. Upwork worked because it is transactional — you can earn on day one. Everything else requires a runway of weeks or months before revenue appears.
What Actually Works (And What I Would Do Differently)
If I could rewind and allocate those 45 hours differently, here is exactly what I would do:
Week 1-2: Go all-in on Upwork (30 hours)
Upwork is the only channel with a direct effort-to-money pipeline for a developer without an existing audience. I would:
- Spend 5 hours perfecting my profile and portfolio pieces
- Apply to 50+ jobs with customized proposals
- Accept any reasonable contract to build reviews
- Target $25-40/hr jobs and work up from there
- Expected revenue: $400-800
Week 3-4: Build one excellent open source contribution (10 hours)
Instead of 11 bounty proposals, I would pick ONE project, join their community, understand their codebase deeply, and submit one high-quality PR. The goal is not the bounty — it is becoming a known contributor who gets assigned future bounties automatically.
Week 5+: Start one content channel with consistency (5 hours/week)
Instead of 82 articles across 6 platforms, I would pick one platform and publish consistently for 3 months. Build an actual audience. Then monetize.
The meta-lesson: Revenue channels exist on a spectrum from transactional (Upwork — work today, get paid this week) to relationship-based (bounties, paid articles — invest months, maybe get paid later). When you are starting from zero, begin at the transactional end. Use the income and credibility from transactional work to fund your transition toward relationship-based channels, which have higher ceilings but much longer runways.
The Uncomfortable Truth About Developer Side Income
Here is what the "I make $10K/month from side projects" crowd does not tell you:
1. Survivorship bias is extreme. For every developer earning significant side income, there are hundreds who tried the same channels and earned nothing. You only hear from the winners.
2. "Passive income" requires massive upfront active investment. The developer with a $5K/month SaaS spent 6 months building it and 6 months marketing it before earning dollar one. They do not mention the 1,000 hours of unpaid work.
3. Most developer side income comes from audience, not code. The highest-earning developer side hustles (courses, content, consulting) are marketing businesses that happen to be about code. If you hate marketing, your earning potential from side projects is severely limited.
4. Your day job is probably your best earner. A developer making $120K/year earns $57/hr. To match that with side income, you need to earn $57/hr on nights and weekends while competing with people who do it full-time. The math rarely works.
5. The market has shifted. The golden era of paid developer content (2018-2022) is winding down. AI can produce tutorial-quality content for free. Publications are cutting budgets. The channels that worked two years ago may not work today.
My Revised Strategy
Based on 45 hours of expensive education, here is my strategy going forward:
Upwork is the revenue engine. It is the only channel where I can reliably convert time to money right now. I am doubling down, raising my rates, and investing in profile optimization.
Stop spraying. No more "try everything and see what sticks." I am picking two channels maximum and going deep.
Build audience before products. The npm packages and Gumroad listings will stay up, but I am not building more until I have a distribution channel (newsletter, Twitter following, or YouTube presence) to drive traffic to them.
Play the long game on bounties. Instead of cold-pitching proposals, I am joining one project's community and becoming a regular contributor first.
Write for learning, not for payment. The 82 articles taught me an enormous amount about web development. That knowledge makes me a better freelancer on Upwork. The articles pay for themselves indirectly even if no publication ever accepts them.
Final Thoughts
I am not writing this to discourage anyone. I am writing it because I wish someone had shown me their real numbers before I started.
The developer side income space is full of survivorship bias, inflated numbers, and courses sold by people whose primary income is selling courses about making income. The reality for most developers — especially those starting from zero with no audience — is far more modest.
Ninety dollars in 45 hours is not a failure. It is data. It tells me exactly where to focus next. And if sharing that data saves even one developer from spending 37 hours on channels that produce zero revenue, this article was worth writing.
The money is there. But it is not where Twitter tells you it is. It is in boring, transactional, client-work-for-money places like Upwork. At least at the start.
Start where the money actually flows. Build the portfolio. Build the audience. Then — and only then — branch out.
Your mileage may vary. But probably not by as much as you think.
Wilson Xu is a full-stack developer who believes in radical transparency about money. You can find his 24 npm packages at npmjs.com/~chengyixu and his work on GitHub at github.com/chengyixu.
Top comments (0)