← Back to Blog

Why I Chose the Independent Developer Path

I wrote my first line of PHP in 2009, long before "indie developer" became a buzzword. Seventeen years later, I've been through employment, entrepreneurship, freelancing, and product building — and I've landed on independent development as my path.

In 2018, I moved into Web3. Blockchain development was still in its infancy back then — Solidity compiler versions were stuck at 0.4.x. I made a decision that turned out to be pivotal: I didn't look for a job. I built my own thing. Not because I was supremely confident, but because Web3's tech stack was evolving so fast that traditional hiring cycles couldn't keep up. By the time a company posted a job description, you'd probably have pivoted to two different tech stacks already.

Since then, I've built XPayLabs — a self-hosted crypto payment gateway that now supports 20+ blockchains and processes real transaction volume daily. Last year, I started GetCiteFlow, an AI search visibility optimization platform that helps websites get cited by ChatGPT, Claude, Perplexity, and other AI-powered search engines.

I'm not listing these to impress you. I'm pointing out a pattern: building your own products + delivering client projects, running on two parallel tracks that reinforce each other.

What draws me to independent development isn't "not having a boss." It's being directly accountable for results. In a large company, your code might go through three layers of approval and five rounds of meetings before it ships — and a year later, you wouldn't even know if it's still running. Independent development is the polar opposite. Every line of code you write, every product decision you make, feeds directly back to you. That feedback loop is incredibly efficient. And brutally honest.

The Three Stages of Independent Development

Stage One: Pure Freelancing — Survive First

When I started freelancing, I had zero buffer. Taking on client projects was the fastest way to generate cash flow.

That period was genuinely tough. Clients came from everywhere — former colleagues referring me, GitHub issue discussions, DMs in tech communities. Between 2018 and 2020, I did smart contract audits, DApp frontends, DeFi protocol consulting, you name it. Some projects were great, with clients who knew exactly what they wanted. Others had requirements that shifted entirely midway through — and you just had to grind through it anyway.

The core objective at this stage isn't making bank. It's building reputation and establishing a cash flow baseline. Enough people need to know you can deliver before you earn the leverage to move to the next stage.

Biggest lesson from this stage: Don't say yes to every project. I once took on a project where the client had a limited budget but promised "there will be many more projects after this." I believed them. After I delivered, the follow-up projects never materialized. I now have an iron rule: evaluate only the current project's value and budget. Never discount your rate for the "promise of future work."

Stage Two: Projects + Products in Parallel — Building Assets

After about two years of freelancing, I hit an uncomfortable realization: freelancing trades time for money, and your total available time is fixed.

Around 2020, I started deliberately carving out time for my own products. The first version of XPayLabs was born this way — I built it during nights and weekends between client projects. The motivation was simple: every crypto payment solution on the market was either expensive (charging 1% per transaction) or came with custody risk that I didn't want to bear.

The hardest part of this stage is energy allocation. Client projects are the bread on the table today. Your own products are the possibility of tomorrow. My rough rhythm was: Monday through Thursday for client work (must deliver), Friday and weekends for my own products. Sounds simple in theory. Executing it requires serious discipline.

Key insight from this stage: Your product doesn't need to be massive from day one. XPayLabs's first version supported only TRON, and its core functionality boiled down to generating payment addresses and monitoring on-chain transfers. It was bare-bones. But it worked. And crucially, it was an asset — regardless of whether I took on client projects that month, it kept running and generating revenue.

Stage Three: Product-Driven — Passive Income as Your Safety Net

Once XPayLabs's user base and transaction volume started growing steadily, my situation shifted.

The most noticeable change was expanded optionality. Before, if a client offered a lower-than-ideal rate, I'd agonize over it — turn it down and risk a dry spell, or take it and feel like I was underselling myself. With product revenue as a cushion, I could say "no" to low-quality projects without anxiety. This isn't arrogance. It's optimized survival strategy.

GetCiteFlow was born during this stage too. With XPayLabs running stably, I finally had an uninterrupted stretch of time to explore a new direction — AI search engine optimization. Without product revenue as a buffer, I couldn't have spent months researching a completely new domain from scratch.

Practical Advice on Freelancing

How to Find Good Clients

I've tried every channel — freelancing platforms, LinkedIn, tech communities. Here's the honest truth: the best clients almost always come through word-of-mouth referrals and community relationships.

I've used Upwork and Fiverr. The experience wasn't great. Clients on these platforms tend to be price-sensitive, and you're competing with developers globally on rate. Compare that to clients who find you through GitHub because of an open-source project you maintain, clients who reach out after reading your technical articles, clients referred by former colleagues or past clients — projects from these channels have far lower communication overhead and far more reasonable budgets.

My advice: invest your time in activities that compound. Maintaining an open-source project on GitHub. Writing a high-quality technical article. Helping someone solve a problem in a community. These things keep generating opportunities long after you've done the work, without you needing to actively "hunt" for them.

Pricing Strategies

After over a decade of trial and error, I now use exactly one pricing model: fixed project pricing. Never hourly.

The problem with hourly billing is that it pits efficiency against income. Work faster and you earn less. That incentive structure is fundamentally broken. With fixed project pricing, you only need to answer one question: what is this project worth?

My process:

1. Define the scope clearly — write a one-page scope document stating exactly what's included and what's not
2. Calculate the baseline using your daily rate multiplied by estimated days. Your daily rate should allow you to live comfortably at a sustainable work pace
3. Add a 20-30% buffer — every project has unforeseen complexity. Don't kid yourself that you can estimate perfectly
4. Bill anything beyond scope separately — your scope document is your moat. Anything outside it is new work with a new price tag

Managing Client Expectations

This skill matters more than your technical ability. Most client dissatisfaction doesn't come from poor execution — it comes from you thinking they understood, them thinking you understood, when in reality nobody understood anything.

My approach now:

• Documentation before code. Before writing a single line, I spend 1-2 days drafting a detailed technical proposal — architecture diagrams, API designs, data structures. Clients may not grasp every detail, but the act itself communicates professionalism. More importantly, it surfaces a ton of ambiguous requirements before they become expensive problems.
• Demo-driven development. Every 1-2 weeks, show the client an interactive demo instead of sending a progress report. "Seeing" is ten thousand times more persuasive than "hearing about."
• Return decisions to the client. You're the developer, not the product manager. When there's a tradeoff decision — say, approach A is faster to build but less scalable, approach B is more flexible but takes longer — lay out the options and tradeoffs clearly, and let the client decide. If things go sideways, it's their decision. You didn't make it for them.

Which Projects to Accept, and Which to Walk Away From

Over the years, I've identified three red flags that make me walk away:

1. "It's really simple, won't take you much time." If the client is estimating your workload, it means they either don't understand tech (communication will be painful) or they're lowballing you (worse)
2. Unwilling to sign a contract or pay a deposit. This sounds obvious, but many independent developers skip this because it "feels awkward." Don't skip it. Without a deposit, the client can cancel anytime and your time investment has zero protection
3. They don't know what they want. "I want to build something like X, but better." This signals that the client hasn't thought things through seriously. The project scope will inflate endlessly, and you'll be filling a bottomless pit

Time Management and Tech Stack Decisions

How to Juggle Products and Client Work Solo

Honestly? It's hard. I've tried every time management methodology out there. What it ultimately boils down to is this: do one deep work block at a time.

Don't write product code, reply to client messages, and fix bugs all in the same morning. From 9 AM to noon, I do exactly one thing — either product code or client work. All communication tools (WeChat, Slack, email) are off. I batch-reply at midday. Then another deep work block in the afternoon.

My typical rhythm:

• Morning (7:00-9:00): Read documentation, scan industry news, handle low-priority messages from yesterday
• Late morning (9:00-12:00): Core coding time, zero interruptions
• Afternoon (13:30-17:30): Client communication, proposal writing, code review (yes, I review my own code)
• Evening (20:00-22:00): Work on my own products (if the morning was spent on client projects)

Why Tech Stack Convergence Matters

When I first started freelancing, I was a sucker for shiny new technology. New framework drops today? I'd want to try it tomorrow. That attitude has completely flipped — stability beats novelty. Familiarity beats fashion.

The reason is simple: your time is finite as a solo developer. Sure, writing a service in Rust might give you better performance — but going from zero to production-ready will cost you an extra month. And that month without project income is a real cost.

My current tech stack logic:

• Frontend: React + TypeScript. Largest ecosystem, easy to hire for if I ever need help. I can do Vue projects too, but my own products are all React
• Backend: Node.js (Express / Fastify). Full-stack capability reuse — one language for front and back
• Web3: Solidity + Hardhat + ethers.js. A battle-tested combo in production
• AI integration: Direct API calls (OpenAI, Claude, and other model endpoints). No self-training models. I'm an application-layer developer, not an AI researcher
• Infrastructure: PostgreSQL + Redis + Docker. The old reliables. They work, they're stable, and when something breaks, I know where to look

You might notice this stack is fairly "conservative." It doesn't have Rust's performance, Go's goroutines, or Svelte's elegance. But it has one massive advantage: when something goes wrong in production, I know how to fix it. That advantage outweighs any benchmark.

The Unfiltered Reality of Independent Development

Income Instability Is the Default

If there's one defining challenge of independent development, it's income unpredictability.

In a good month, hitting six figures isn't hard. But the next month might bring in a third of that. The psychological impact of this fluctuation far exceeds the financial one. You need a specific skill: staying grounded when income spikes, and not panicking when it dips.

My two-part strategy:

• Don't treat project income as a "salary." After each project payment, I set aside taxes and essential living expenses first. Everything remaining goes into product development reserves and investments
• Product revenue is your safety net. XPayLabs's recurring monthly income means I don't have to anxiously wonder "where's the next project?" every single month. If you're considering the independent developer path, I strongly recommend starting a product early

Loneliness — and How to Deal With It

Coding alone. Making decisions alone. Debugging alone. This loneliness is the biggest hidden cost of independent development.

In a company, you can turn to a colleague when you hit a technical wall. As an independent developer, you carry it all yourself. I've had nights where production went down and I was alone, staring at logs until 3 AM. Not a great feeling.

My solutions:

• Stay active in open source. You don't need to build everything from scratch. Contributing to open-source projects keeps you connected with developers worldwide, and gives you people to discuss problems with
• Join indie developer communities. The indie hacker circles on Twitter/X, various Discord servers — talk to people. You'll quickly discover that the problems you're facing have been solved by someone else already
• Write and share. Part of why I'm writing this article is that sharing your experience is in itself a process of self-reflection and external connection

Health Is Not Optional

In 2019, I developed a serious lumbar spine issue from prolonged sitting. At its worst, I couldn't sit for more than 20 minutes without searing back pain. It took over half a year to recover, and that entire period was hell for both freelancing and coding.

Now I treat exercise with the same priority as writing code: minimum 30 minutes of exercise daily (running, swimming, or strength training), and I stand up and walk for 10 minutes after every 50 minutes of sitting. This isn't a suggestion — it's non-negotiable.

No matter how skilled you are, your body is your core infrastructure. If that infrastructure collapses, everything stops.

Closing Thoughts

I'm not writing this to sell you on independent development — or to warn you off it. The honest truth is, it's not for everyone.

If you value certainty — a stable paycheck, clear promotion paths, a consistent social circle — then being a senior engineer at a big tech company is an excellent path too. Many of my friends in big tech are doing great work, with technical depth and resources that independent developers simply can't match.

But if you're the type who prefers steering your own ship, can tolerate uncertainty, has a strong sense of ownership over results, and genuinely enjoys the process of building something from zero to one — then independent development might be your path.

It's not an easy road. But the freedom and growth it offers are unparalleled. You never have to explain to anyone why you're building something. You never do overtime for someone else's KPIs. Every line of code you write is building your own assets.

If you're on the fence about starting, my advice is: don't quit your job yet. Use weekends and evenings to build a small SaaS product — even if it only brings in $50 a month. That journey from zero to one will tell you whether this path is for you. If it works, you'll have the confidence to go all in. If it doesn't, you haven't lost anything.

My Discord server is always open to independent developers. If you run into specific challenges, come find me. This road doesn't have to be walked alone.