Coder Legion - Recent posts tagged freelancing

The Remote Developer Math Most Offers Leave Out

Fri, 02 Oct 2026 15:42:51 +0000

A lot of us here work remotely or are weighing a remote offer against an office one, and the salary is usually the only number that gets compared. Here is the rest of the math, the parts that decide what a remote role is really worth and what a freelance setup lets you keep.

Compare the Offer, Not Just the Salary

Some employers pay one national rate wherever you live. Others adjust pay by location, which can mean 10 to 30 percent less after a move away from a high cost city.

Then add back what the office was costing you. Commuting alone runs the average American $8,500 to $12,000 a year in transportation and lost time, before lunches and work clothes. That is how a $75,000 remote role can leave more in your pocket than an $85,000 office one. This work from home guide breaks realistic pay down by role, from support work up to senior engineering.

If You Freelance or Contract, the Home Office Pays You Back

Employees mostly have taxes handled through payroll. Contractors and freelancers get the deductions instead. The home office deduction covers a share of rent or mortgage interest, utilities, internet and insurance, based on the part of your home used only and regularly for work.

The simplified method is $5 per square foot up to 300 square feet, a $1,500 ceiling, while the regular method uses your actual costs. Equipment, software subscriptions, health insurance premiums and retirement contributions like a SEP IRA come off too.

Watch the State Line

If you live in one state and your employer is in another, you can owe tax in both. Some states have reciprocity agreements that prevent it, while New York taxes many remote workers based on where the employer is rather than where they sit. A quick check before signing an out of state offer saves a surprise in April.

Stay Visible on Purpose

Remote developers rarely fall behind on performance. They fall behind on visibility. Regular one on ones with your manager, writing down your wins and sharing them before review season, and volunteering for cross team work close most of that gap.

The Takeaway

Before comparing two offers, compare what each one costs you to accept. The salary is only one line of that math.

Tech Side Hustles for Developers: Pick by Hours, Not by Hype

Sat, 26 Sep 2026 16:23:50 +0000

Most of us here already have the skill that makes a side hustle easy to start, since we write code for a living. The hard part is not the idea, it is picking something that still fits your week after a full day of shipping at work.

Start With Honest Hours

The most common side hustle mistake is choosing by income potential alone. A project that could earn $5,000 a month but needs 30 hours a week does not survive next to a demanding dev job, while one that pays $800 on 5 hours a week can run for years and compound. Most side hustles need 5 to 10 hours a week to show results and 15 to 20 to become real income, so count the hours you can give every week for six months, not the ones you hope to free up. This side hustle guide with startup costs and realistic income for each type is a good place to compare options before you commit.

Sell the Skill You Already Have

Developers get to skip the longest part of starting, the learning curve. Freelance web development runs roughly $50 to $200 an hour, and custom Shopify or WooCommerce builds are steady work because small shops keep needing them. A developer who builds Shopify stores for small businesses can charge $1,500 to $5,000 per project and finish one or two a month on evenings and weekends.

Time for Money Versus Building Assets

Every side hustle sits somewhere between trading time for money and building something that earns without you. Freelancing pays from the first client but caps out at the hours you can work. Digital products like templates, courses or small software tools take weeks to build, then sell again and again with margins close to 100 percent. A realistic path for most developers is to freelance first for cash flow, then turn the things you keep rebuilding for clients into products.

Treat It Like a Business From Day One

Once side income passes $600 a year it has to be reported, and past $1,000 you should be making quarterly estimated payments. Self employment tax runs 15.3 percent of net income, so a simple spreadsheet of income and expenses from the start saves a painful tax season.

The Takeaway

Pick the side hustle that fits your real week and uses the skills you already get paid for, then add products once the first income stream is steady. Moving to full time makes sense once the side hustle covers about 75 percent of your take home pay for three months in a row and you have 6 to 12 months of expenses saved.

Freelancing as a Developer: Pick a Niche, Then Price the Project

Fri, 25 Sep 2026 15:50:05 +0000

A lot of us here have taken on a client project on the side or thought about going independent. This is a short guide to the parts of freelancing that trip developers up most, written from the developer side of the table.

Why a Niche Beats a Stack

Most developers describe themselves by stack: React developer, Python developer, full stack. Clients don't buy stacks, they buy solved problems. A generalist ends up competing on price because a client can't tell one "I build anything" profile from the next. "I build booking and payment flows for Shopify stores" competes with a far smaller group, and those clients pay more because they need exactly that. Start where your existing skills meet an industry you already understand, then narrow as you learn which work clients value most. This complete guide to starting a freelance career walks through choosing a niche and finding the first clients for it.

Hourly, Project or Retainer

Hourly works when the scope genuinely can't be known up front, like debugging someone else's legacy system or open ended consulting. Project pricing, a flat fee for a defined deliverable, fits most builds, and it rewards you for being fast instead of penalizing you for it. Retainers, a fixed monthly fee for maintenance or a set number of hours, give you income you can predict, which matters more than the rate once you are doing this full time.

Whatever you pick, don't open low to win the first job. Low rates attract the clients who ask for the most revisions and pay the slowest, and a rate set too low is much harder to raise than one set fairly.

Contracts Are How You Stop Scope Creep

"Can you just add one more screen?" is where freelance projects quietly lose money. A written contract that lists the deliverables, the timeline, the number of revision rounds, the payment terms and who owns the code turns that question into a change request with a price on it. It protects the client too, because both sides can point at the same document when something goes sideways. Never start work on a handshake, however trustworthy the client seems.

Taxes Nobody Withholds for You

In the US, going independent means paying self employment tax of 15.3 percent on top of income tax, with estimated payments due quarterly in April, June, September and January. The habit that saves most people is moving 25 to 30 percent of every payment into a separate account the day it arrives. Invoicing tools like Wave (free) or FreshBooks keep the records you need at tax time.

The Takeaway

The code is usually the easy part. Picking a narrow niche, pricing the project instead of the hour, and putting the scope in writing are what make freelancing sustainable for developers.

Five Years of Not Giving Up — Anas Sheikh’s Journey as a Developer

Wed, 09 Sep 2026 08:52:50 +0000

Five Years of Not Giving Up — My Journey as a Developer

Five years ago, I had no idea where programming would take me.

It started with my cousin.

He had started learning programming, and one day he recommended that I give it a try too. I didn't immediately jump into it. I took some time to think about whether programming was really something I wanted to do.

A few days later, I finally decided to start.

I opened YouTube and began with HTML.

There was no expensive course, no perfect roadmap, and no shortcut.

Just me, YouTube tutorials, and a lot of curiosity.

From YouTube Tutorials to Real Projects

After HTML, I started learning CSS. I watched tutorials and then tried to build small projects myself.

I would build something, break it, try to fix it, and then build it again.

And I kept doing that.

Day after day.

I became obsessed with practicing. I couldn't stop.

After HTML and CSS, I started learning Bootstrap. That alone took me almost two months.

Then, after around six months of learning and practicing, I started JavaScript.

JavaScript was a completely different experience.

There were so many concepts I didn't understand at first. I spent countless hours watching tutorials, trying things myself, getting confused, going back to the tutorials, and trying again.

But I didn't quit.

My cousin and I eventually got an unpaid internship at a software house. He got a job there later, but I remained on the unpaid internship.

I stayed there for almost eight months.

For those eight months, I wasn't earning a salary. My father supported me with my basic daily expenses. I would usually need around 100 PKR for bike petrol and some snacks, while I brought lunch from home.

It wasn't easy.

I was trying extremely hard to get a job, but I couldn't find one.

Learning by Building

Eventually, I left the software house and continued learning and building from home.

But leaving didn't mean stopping.

It meant I had to push myself even harder.

During that period, I continued building projects and also started learning React.js.

At the software house, I had another friend who was also an unpaid intern. We spent our time learning from YouTube and building small projects together.

We built things like calculators, to-do list applications, and other small projects.

They weren't impressive products.

But they were important.

Every small project taught me something.

Every bug forced me to think.

Every time I broke something and fixed it, I understood programming a little better.

Looking back, those small projects were some of the most important projects I ever built because they taught me how to learn.

Another Opportunity

After I left, around two or three months later, my cousin also left that company and got another job.

He invited me to join him.

The role was for a React.js frontend developer.

I had learned React, but I had only been working with it for around four months.

And honestly, I wasn't confident.

This was before AI coding tools became as popular as they are today. I was scared of giving the interview because I didn't feel ready.

My cousin got the job.

I didn't.

I continued working as an unpaid intern at another company.

And this time, something different happened.

I met an amazing senior developer.

He was a very strong full-stack developer, and he taught me a lot. He trusted me with real work, explained things to me, and connected me with real company projects.

For the first time, I wasn't just building tutorial projects.

I was working on real projects for real clients.

And I loved it.

I was still unpaid, but I didn't stop.

I kept learning.

I kept working.

I kept coding.

I think that's when I realized that I genuinely loved programming.

I could do the same thing again and again — build something, break something, fix something, learn something new — and still enjoy it.

The Job I Didn't Take

Eventually, I decided to ask the company if they could give me a paid position.

My senior supported me and spoke to the manager.

The manager asked me about my salary expectations.

I said 40,000 PKR.

My cousin was earning around 80,000 PKR at that time.

Then the manager said something I will never forget:

They could give me the job, but they would have to fire my cousin.

I immediately said no.

I couldn't accept a job if getting that job meant replacing the person who had supported me from the beginning.

My cousin had been one of the reasons I started programming in the first place. He had supported me throughout the journey.

So I rejected the offer.

I told my cousin what happened, and we decided to leave the company.

Instead of continuing to look for jobs, we decided to try something completely different.

We started freelancing.

My First 60K PKR

We started getting projects through my cousin's Fiverr account.

I still remember completing our first project.

When my cousin gave me my share, it was around 60,000 PKR.

I was incredibly happy.

I remember crying.

Not because 60,000 PKR was some huge amount of money.

It was because of what that money represented.

For almost two years, I had been learning.

I had spent months doing unpaid internships.

I had spent countless hours watching tutorials.

I had built project after project.

I had tried to find a job and failed.

And then, finally, someone had paid me for the skill I had worked so hard to develop.

That 60,000 PKR was my first real earning from programming.

I will never forget that feeling.

The Next Step: Learning Next.js

After that first 60,000 PKR, something changed for me.

I didn't think, "I've made it."

Instead, I became even more motivated to improve.

I started paying more attention to what other developers were using and what technologies were becoming popular in the industry.

At that time, I started seeing more and more developers recommending Next.js, especially for building production websites and applications.

I had already spent a lot of time learning JavaScript, so I had a strong foundation.

That made it much easier for me to understand React and then move into Next.js.

I decided to learn it.

And this time, it was different.

I wasn't starting from zero anymore.

I already understood JavaScript, components, frontend development, APIs, and how web applications were structured.

So I went deep into Next.js and managed to learn the fundamentals and start building with it in roughly one month.

I started using it in real projects and continued learning through actual client work.

Today, Next.js has become one of the main technologies I work with.

Most of the modern web projects I work on are built around React and Next.js.

Don't Just Chase Frameworks

One of the biggest things I've learned is:

Don't just chase frameworks. Build strong fundamentals.

Frameworks change.

Tools change.

The way we build software changes.

But if your fundamentals are strong, learning the next technology becomes much easier.

Freelancing Became My Career

After that first project, we didn't stop.

We continued getting projects and working with real clients.

Eventually, I created my own Fiverr and Upwork accounts as well.

Over time, I had the opportunity to work with some amazing people. Some clients continued working with me again and again.

One thing that makes me especially proud is that throughout this journey, I don't remember having a client who was genuinely unhappy with my work.

Clients appreciated the work.

Some gave me tips.

Some came back with more projects.

And slowly, my skills improved with every project.

I learned not just how to code, but how to communicate with clients, understand requirements, solve real problems, manage projects, handle feedback, and deliver something that another person could actually use.

Freelancing gave me something I couldn't get from simply learning programming tutorials.

It gave me real experience.

Five Years Later

Today, it has been five years since I started this journey.

And one interesting thing about my story is that I still haven't had a traditional full-time developer job.

For a long time, I thought that was something I should be worried about.

But freelancing gave me almost everything I was looking for.

It gave me real clients.

Real projects.

Real responsibility.

And the freedom to work on different kinds of products and technologies.

I've worked with modern web technologies including React, Next.js, JavaScript, TypeScript, Tailwind CSS, databases, APIs, CMS platforms, cloud services, and many other tools.

But more importantly, I've learned how to learn.

And I think that is one of the most valuable skills a developer can have.

Building for Real Problems

Over time, I've also become increasingly interested in building products that solve real problems rather than simply building websites.

One example is an idea around improving patient queues in Pakistani hospitals.

The goal is to reduce manual queue management, help patients understand when they may see a doctor, and make the process easier for both patients and hospital staff.

Working on problems like this reminded me why I started programming in the first place:

Not just to write code, but to solve problems.

What About AI?

Today, AI is changing the way developers work.

Some people are worried that AI will replace developers.

I don't see it that way.

AI has changed my workflow, but I see it more as a tool that helps me work faster.

Things that used to take much longer can sometimes be done much faster now.

A project that might have taken two months can sometimes be completed in a month.

But the developer still needs to understand what they are building.

You still need to understand the problem.

You still need to make decisions.

You still need to debug.

You still need to know when AI is wrong.

AI can make development faster, but I don't believe it removes the need to learn.

If anything, I think developers should focus even more on understanding fundamentals, problem-solving, communication, product thinking, and how software actually works.

Don't be afraid of AI. Learn how to use it.

The Biggest Lesson I've Learned

If there is one lesson I would share from my five-year journey, it is simple:

Be consistent. Don't stop.

There were many moments when I felt behind.

There were times when I couldn't get a job.

There were months when I worked without getting paid.

There were countless bugs I couldn't understand.

There were technologies that felt impossible when I first started learning them.

But I kept going.

I kept opening my laptop.

I kept watching tutorials.

I kept building.

I kept breaking things.

I kept fixing them.

And eventually, those small efforts started adding up.

I didn't become a developer in one day.

There wasn't one magical moment when everything suddenly made sense.

It happened slowly.

One project at a time.

One bug at a time.

One client at a time.

One lesson at a time.

Looking Back

Sometimes I think about the person who opened YouTube five years ago and started learning HTML.

He had no idea what was coming.

He didn't know about React.

He didn't know about Next.js.

He didn't know about freelancing.

He didn't know that one day he would be building real projects for clients around the world.

He definitely didn't know that his first programming income would make him cry.

But he kept going.

And I'm glad he did.

The last five years haven't always been easy.

Actually, some parts were really hard.

But they were worth it.

I'm proud of the journey — not because everything went perfectly, but because I didn't give up when things didn't go according to plan.

And I'm still learning.

I'm still building.

I'm still making mistakes.

I'm still breaking things and fixing them.

And honestly, I still love it.

If You're Just Starting

So if you're reading this and you're just starting your programming journey, don't worry if you're not good yet.

Don't worry if you don't get a job immediately.

Don't worry if everyone around you seems to be progressing faster.

Keep learning.

Keep building.

Keep practicing.

Keep showing up.

Be consistent. Don't stop.

Your journey may take longer than you expect.

Mine certainly did.

But sometimes the longest journeys are the ones that are worth the most.

Thank you for reading my story.

I hope it gives even one developer the motivation to keep going.

About Anas Sheikh

Anas Sheikh is a developer who has built his career through continuous learning, freelancing, and working on real-world projects.

His journey has taken him from learning HTML and CSS through YouTube tutorials to working with React, Next.js, TypeScript, Tailwind CSS, APIs, databases, CMS platforms, and cloud services.

More importantly, his story is about persistence — continuing to learn and build through unpaid internships, job rejections, difficult periods, and countless bugs.

View Anas Sheikh's CoderLegion Profile

Developer: Anas Sheikh
Series: CoderLegion Developer Stories
Interviewed and edited by: Mehadi Hasan, Community & Editorial Team, CoderLegion

The Missing Freelance Time Tracker

Sat, 01 Aug 2026 10:02:43 +0000

The Missing Freelance Time Tracker

It has a name now: MelaFreelance. Here's what it is, and why it's yours — not mine.

In the last piece I explained the itch: every time tracker I tried was built for teams, and I'm one person with a client, a project, and a clock. So I stopped renting other people's tools and built the small one I actually needed.

This is that tool. It's called MelaFreelance, and this is what it turned out to be.

Built one summer, polished the next

The first commit landed in August 2025, in the slow, warm gap where the client emails thin out and there's finally room to make the thing you keep meaning to make. It wasn't pretty. It had no options, no settings, no polish — just the raw mechanics I needed to answer who owes me what. And then I did the most honest test there is: I used it. Every day, for a straight year, exactly as it was.

A year of real use is a brutally good editor. It tells you which features you invented and never touch, and which rough edges you step over so often you stopped noticing. Nothing survives that a design doc would have kept, and nothing gets cut that you actually reach for.

So here we are, another August, the same quiet slice of the calendar — and this time the work isn't building it, it's finishing it. The polish it earned by proving, over twelve months, that it deserved to exist.

There's a second reason the timing is right. Lately I've been deep in a much heavier project — S-MoE, a sparse mixture-of-experts build that lives in exactly the kind of complexity you can't hold in your head on a hot afternoon. After enough of that, coming back to MelaFreelance feels like stepping out of a machine room into the sun. Small surface, clear edges, an obvious right answer for every question. Simple work — but not unimportant work. Sometimes the most useful thing you can build is the one you can finish.

It's yours, not mine

Here's the decision that shapes everything else: MelaFreelance isn't a service you sign up for. It's a thing you run.

There's no account on my server, no subscription, no "free tier" quietly counting your clients until it asks for a card. You clone it, you point it at your own database, and it's yours — data and all. If I vanish tomorrow, your tool keeps working, because it was never on a server I control.

That's not an accident, it's the whole philosophy. The tools that broke me in the first place all had one thing in common: my data lived in their product, on their terms, one pricing-page change away from held hostage. A tracker for freelancers should be the one piece of software a freelancer never has to worry about losing.

So it's single-user by default — no seats, no invites, no "workspace." One person clones it, runs one command to create their account, and starts working. Everything about it assumes you are the only human who will ever log in, because for me, that's the truth.

The timer that's always there

The most-used thing in a time tracker is the start/stop button, so I refused to bury it.

In MelaFreelance the running timer isn't a widget you navigate to — it lives in the app's chrome, on every page. Wherever you are, you can see what's ticking and stop it. And there's exactly one rule the app enforces for you, quietly: you can only run one timer at a time. Start a task while another is running and the old one banks its minutes and stops on its own. A freelancer works one thing at a time; the tool should never let two clocks claim the same minute.

When you stop, the bar doesn't just disappear. It remembers the last thing you were on — "was I still on the Rossi homepage?" — with a one-click Resume, until you dismiss it. Small thing. I use it twenty times a day.

The number that matters

Open the app and the first thing it tells you is the number I actually came for: what am I owed, and what's still outstanding?

Not tracked hours dressed up as money. Not an invoice-count vanity stat. Just: across every project, how much has been paid, and how much is still out there. Because payments in MelaFreelance are a ledger, not a checkbox — a deposit, a milestone, a final balance — "paid" and "outstanding" are simply the arithmetic on that ledger. And the arithmetic is done once, on the backend, in whole cents, so the number on your dashboard is the number, every time. No rounding drift, no two screens disagreeing.

Money can be windowed — received this month — because every payment carries a date. Hours are all-time, on purpose: a task holds one running total, not a pile of dated entries I'd have to maintain. That asymmetry is a feature. It's the difference between a tool that answers your question and a tool that invents new ones to justify itself.

Still small on purpose

I've added things since launch — a gentle nudge to mark a project done when its last task finishes, a proper time picker, non-billable projects for the client called "Myself." But the rule hasn't changed: nothing ships unless I hit the need for it in my own week.

That's the luxury of building for exactly one user. There's no roadmap to defend, no enterprise deal bending the design, no feature added to win a comparison chart. When something annoys me, I fix it. When something's missing, I add it. When it's fine, I leave it alone — which is most of the time, and exactly the point.

MelaFreelance is free, it's open, and it's built to be cloned. If you're a freelancer who's tired of renting the basics, you don't have to wait for me to build your features. You can take it and make it the tool you needed all along.

That was always the missing one. Built in one summer, quietly proven through a year of real work, and finished in the next. If a tool can earn that, it's earned a place on your machine too.

MelaFreelance — built by a freelancer, for freelancers. Clone it, own it, get back to the work.

I Tried Every Time Tracker Made for Teams. So I Built One for Freelancers.

Mon, 27 Jul 2026 10:30:00 +0000

Why the "simple" tool I needed didn't exist — so I made it.

For years I did what most freelancers do: I borrowed tools built for someone else.

Every time-tracking app I reached for was beautiful. Polished onboarding, slick dashboards, thoughtful animations. And every single one of them was built for teams — for managers assigning work, for sprints, for capacity planning across ten people. I'm one person. I don't have a sprint. I have a client, a project, and a clock.

The gap was always the same: the basics I actually needed as a freelancer were either buried under features I'd never touch, or locked behind a paywall — while the twenty features I didn't need were front and center and free.

The Asana + Everhour era

Most recently I settled on Asana's free plan. It's genuinely good software. But Asana doesn't track payments — and payments are half of my job. Did the client pay the deposit? What's still outstanding on the fixed-price quote? That's the number that actually keeps the lights on, and it simply wasn't there.

So I bolted on Everhour. It worked. It tracked time, it tracked money. But it also did a hundred other things, most of which I'd never use — and it was one more paid subscription stacked on top of another.

Here's the part that finally broke me: I started spending more time diagnosing my tools than using them. Reconnecting integrations. Fiddling with settings that existed to serve workflows I don't have. The tools were supposed to save me time. Instead they'd quietly become another client — one that never paid me.

What a freelancer actually needs

When I stripped it back, my real requirements fit on a sticky note:

Clients. People who owe me money.
Projects. With a rate — hourly, a fixed agreed fee, or nothing at all for personal work.
Tasks. With a timer. Start, stop, done.
Payments. Not a single "paid" checkbox — a real ledger. Deposits, milestones, the final balance. What's paid, what's outstanding.
A way to close things. Mark a task done. Mark a project complete. Watch the finished work step out of the way so I can see what's still live.

That's it. That's the whole job. No sprints, no assignees, no story points, no "workspaces." Just: who owes me what, how much have they paid, and am I done?

So I built it

I built a small tool that does exactly that and nothing more. I want to be clear about what it isn't: it's not trying to compete with Asana, Toggl, Everhour, or any of the excellent products in this space. Those are wonderful tools for the teams they're made for.

This is just the opposite bet — small on purpose.

A few decisions I'm quietly proud of:

Billing mode is implicit. Set an agreed fee and it's a fixed-price project — your tracked time becomes reference, not the bill. Leave the fee blank and it bills by the hour. Set the rate to €0 and it's non-billable — because sometimes the client is "Myself" and I still want to know how many hours my own website ate.
Payments are a ledger, not a flag. A 30% deposit up front, a milestone halfway, the balance on delivery — the way freelance money actually moves. "Paid" and "outstanding" are just math on that ledger.
Completion is gentle. Finish the last task and the app suggests marking the project done. It never does it behind your back. (And a fully-paid project can't be quietly reopened — because that's a mistake, not a workflow.)

No feature exists unless I actually hit the need for it. That constraint is the whole point.

The lesson

The best tool isn't the one with the most features. It's the one that disappears — the one you use without thinking, that gives you back the number you came for and gets out of the way.

For years I assumed that tool had to be bought. It turns out it just had to be honest about who it was for.

It's free. It's simple. It's actually useful — to me. And if you're a freelancer who's ever felt like a rounding error in software built for teams of fifty, maybe it's for you too.

Built by a freelancer, for freelancers. Not to disrupt anything — just to finally stop diagnosing my tools and get back to the work.

Repo link --> https://github.com/melasistema/clients-melasistema