DEV Community: Lucas Rego

8 Real Ways Developers Make Money in 2026 (Ranked by Effort)

Lucas Rego — Fri, 22 May 2026 23:19:37 +0000

Every "make money as a developer" post promises passive riches by Friday. This isn't that.

I've tried most of these. Some paid rent. Some paid for coffee. One quietly pays me while I'm asleep. Below is an honest ranking — sorted from "most effort for the money" to "least" — with realistic timelines and the catch for each, because the catch is the part nobody writes about.

1. Freelancing / contracting

Effort: High · Time to first dollar: 1–6 weeks · Ceiling: Very high

Still the fastest reliable path. Upwork and Fiverr are crowded races to the bottom; the money is in Toptal, Contra, Gun.io, or — best of all — your own network. Your second client should come from your first client's referral, not a bidding war.

The catch: You're trading hours for money, plus the unpaid hours of finding clients, scoping, and chasing invoices. It's a business, not a side hustle. Treat it like one or it'll treat you like one.

Tip: Niche down. "React developer" competes with 200,000 people. "I rescue stalled Next.js migrations for B2B SaaS" competes with almost none and charges 3x.

2. Build and sell digital products

Effort: High up front, low after · Time to first dollar: 1–3 months · Ceiling: High

Boilerplates, UI kits, Notion templates, VS Code themes, icon sets, Figma files, code generators. Build once, sell forever. Gumroad, Lemon Squeezy, and the GitHub Marketplace make distribution trivial.

The winners solve a boring problem you've already solved for yourself. Auth boilerplate. A Stripe + webhooks starter. A deploy script you keep copy-pasting.

The catch: "Build once" is a lie — you'll support, update, and market it forever. Distribution is 80% of the work and writing the code was the fun 20%.

3. Micro-SaaS / indie hacking

Effort: Very high · Time to first dollar: 3–12 months · Ceiling: Life-changing

The dream: a small product with recurring revenue you own end to end. Totally real — see the indie hackers shipping $5–50k/month tools. Also where most developers quietly burn six months and ship to crickets.

The catch: The hard part isn't the code, it's finding a problem people will pay for before you build. Talk to users first. Charge from day one. If nobody pays for the landing page, nobody pays for the product.

4. Teaching: courses, YouTube, cohorts

Effort: High · Time to first dollar: 2–6 months · Ceiling: High

Udemy, YouTube, Egghead, or your own cohort-based course. You don't need to be the world's best engineer — you need to be one chapter ahead of your audience and good at explaining.

The catch: It compounds slowly and publicly. Your first 20 videos will flop. The audience is the asset, and audiences take a year+ to build.

5. Technical writing

Effort: Medium · Time to first dollar: 2–4 weeks · Ceiling: Medium

Companies pay $200–$1,000+ per article for quality developer content. Dev tool companies (databases, auth, observability, anything DX-focused) constantly need writers who can actually code. Check Draft.dev, the DevRel job boards, or just pitch companies whose tools you use.

The catch: You need writing samples to get hired to write. Publish a few strong posts (like this one) on your own blog or dev.to first, then point to them.

6. Open source sponsorship

Effort: Medium-high · Time to first dollar: Slow · Ceiling: Medium

GitHub Sponsors, Open Collective, Polar. If you maintain something people depend on, companies and individuals will fund it. Some maintainers fund full-time work this way.

The catch: Sponsorship follows traction, not the other way around. This pays because your project is useful to thousands, which is years of unpaid work first. Treat it as upside on work you'd do anyway, not a plan.

7. Bug bounties

Effort: High · Time to first dollar: Unpredictable · Ceiling: Very high

HackerOne, Bugcrowd, Immunefi (the last one pays eye-watering sums for smart-contract bugs). If you genuinely enjoy breaking things, the top hunters out-earn senior salaries.

The catch: Brutally feast-or-famine and steep learning curve. You can spend 40 hours and find nothing, or one hour and find $20k. Most people find nothing for a long time.

8. Get paid for your profile — even when you're not job hunting

Effort: Low · Time to first dollar: Days · Ceiling: Modest (but truly passive)

Here's the one most developers haven't tried, and the reason I wrote this list.

Think about your last job search. If someone had paid you $100/hour to do it, what would you have earned? Probably thousands. Instead, companies pay for recruiters, job boards, and ads to find you — and you, the actual product, get nothing.

A newer platform called Timofi flips that. You record a short set of clips — basically a mini interview (how you think, a project you're proud of, a tradeoff you'd defend) — and drop one link on your LinkedIn, GitHub, or resume. When a recruiter wants to unlock it and actually see you talk, they pay a small fee, and you keep 60%.

The part that sold me: it works even when you're not looking for a job. If you're a solid engineer, recruiters already DM you constantly and you ignore them. This makes the good ones pay for your attention. Worst case, someone unlocks, watches, and nothing comes of it — you still got paid for the time. The downside has a floor.

The honest catch: It's early. The broader hiring marketplace is rolling out gradually, and your earnings scale with how much profile traffic you actually have — so it pays best if you already get inbound from recruiters. It won't replace your salary. Think "found money on traffic you were ignoring anyway," not "quit your job." Setup takes a few minutes, so the effort-to-upside ratio is hard to argue with.

Full disclosure for the dev.to crowd: I think this category — getting paid for your own attention — is genuinely new, which is why it's on the list. Try it, don't try it, but the framing alone is worth stealing.

So which one should you actually pick?

Need money this month? → Freelancing (#1) or technical writing (#5).
Want something that compounds? → Products (#2), teaching (#4), or micro-SaaS (#3).
Want upside on work you already do? → Open source sponsorship (#6) or your profile (#8).
Love breaking things? → Bug bounties (#7).

The meta-lesson across all eight: stop giving your work, your time, and your attention away for free. Whether you package it as a product, a course, an article, or a paid mini interview — the developers who make money are the ones who decided their output has a price tag.

Which of these have you tried? What worked, what flopped? Drop it in the comments — genuinely curious what's paying for the dev.to crowd in 2026.

What I Look for When Hiring Remote Full-Stack Developers (React + Node.js)

Lucas Rego — Mon, 27 Apr 2026 17:13:53 +0000

What I Look for When Hiring Remote Full-Stack Developers (React + Node.js)

After years of building and leading remote engineering teams, I've reviewed hundreds of applications, conducted dozens of interviews, and worked alongside developers from every continent. Along the way, I've learned that the best hires rarely have the most polished resumes — and the worst hires often look great on paper.

If you're a developer looking to land a remote full-stack role, or a hiring manager trying to figure out what actually matters, here's what I've learned. At the end, I'll share how our own hiring process works and how you can apply.

1. The Tech Stack Is Table Stakes

Every job post lists the same things: React, Node.js, TypeScript, REST, SQL, Git. If you're applying for a full-stack role, I assume you can write a functional component, set up an Express server, and write a SQL query without panicking.

What I'm actually looking for is how you use these tools:

Can you explain why you chose useMemo here instead of useCallback?
Do you understand the difference between authentication and authorization, or do you just app.use(authMiddleware) and hope for the best?
When an API is slow, do you reach for caching, or do you actually profile the query first?

The stack on your resume tells me what you've touched. The way you talk about it tells me whether you understand it.

2. Communication Beats Cleverness

Remote work amplifies everything — the good and the bad. A brilliant engineer who can't write a clear PR description or explain their reasoning in a Slack thread will slow down the whole team.

The best remote developers I've worked with all share these habits:

They write it down. Decisions, tradeoffs, blockers — all documented, not buried in a DM.
They ask good questions. Instead of "this doesn't work," they share what they tried, what they expected, and what actually happened.
They over-communicate by default. A quick "I'm looking into this, will update by EOD" is worth more than three hours of silence.

When I'm reviewing applications, a well-written cover note or a thoughtful README on a GitHub project tells me more than another bullet point on a resume.

3. Self-Direction Without Going Off the Rails

Remote work means nobody is going to tap you on the shoulder. You need to figure out what to do, do it, and know when to pull other people in.

The trap I've seen developers fall into is one of two extremes:

Disappearing into a feature for two weeks and surfacing with something nobody asked for
Asking permission for every micro-decision and stalling waiting for replies across time zones

The sweet spot is somewhere in between: make the call when you can, document it, and flag the things that genuinely need input. This is a skill, not a personality trait — and it's one of the strongest signals I look for.

4. Code Quality That Respects Other Humans

I don't care if your code is "clever." I care if the next person who reads it (which might be you in three months) can understand what it does and why.

Things I notice in code reviews and take-home tests:

Naming. Are variables and functions named for what they do, or are they named data, temp, handleClick2?
Structure. Is there a clear separation between business logic, data access, and UI?
Tests. Even a few well-written tests tell me you think about edge cases and care about not breaking things.
Error handling. Do you handle the unhappy path, or does everything assume the network is perfect and users always behave?

You don't need to be a "clean code" zealot. You just need to write code like you expect someone else to read it.

5. Curiosity About the Product, Not Just the Code

The developers who grow fastest on remote teams are the ones who care about why they're building something, not just what they're building.

When I interview someone, I love hearing questions like:

"Who are the users for this feature?"
"What problem are we actually solving?"
"Have you considered doing it this other way?"

These questions tell me you're going to be a partner, not just a code-writing machine. And on a remote team, where context is harder to absorb, that mindset is gold.

How Our Hiring Process Works

We're currently hiring full-stack developers for full-time remote positions. Our process is built to respect your time and give you a real sense of how we work — no whiteboard riddles, no trick questions.

Here's how it works:

Sign up at app.timofi.com. This is where the entire process happens — your profile, the technical assessment, and communication with our team. Creating an account takes a couple of minutes.
Complete the technical assessment. As part of your application, you'll take a practical test that reflects the kind of work you'd actually do on the job. It's designed to be fair and focused — we're looking at how you think and write code, not whether you've memorized obscure algorithms.
Interview with the team. If your assessment looks good, you'll meet with us to talk through your experience, the test, and what you're looking for in your next role. This is also your chance to ask us anything.
Get an offer. If it's a fit on both sides, we move forward. We aim to keep the whole process tight — no ghosting, no month-long silences.

If you're a full-stack developer with solid React and Node.js experience and you're looking for a remote role with a team that values clear communication and good engineering, head to app.timofi.com to get started.

Final Thoughts

Hiring remote is hard. Getting hired remote is also hard. But when both sides focus on the things that actually matter — communication, judgment, code that respects the next reader, and genuine curiosity about the work — the rest tends to fall into place.

Good luck out there. And if you're ready to apply, you know where to find us.