Why I Like Working on Multiple Freelance Projects at Once

One thing I often do: take on more than one freelance project at a time, rather than focusing on a single client. To some people that sounds exhausting — and honestly, sometimes it is — but for me there are real benefits that keep me choosing this way of working.

Variety keeps skills sharp

A desktop tools project (Avalonia, Go) needs a very different skillset from a mobile app project (Swift/Kotlin) or an internal web app (React/Spring Boot). Switching contexts like this keeps me from getting stuck on just one type of problem. There have been moments where I was stuck debugging a race condition in a desktop tool, switched over to a React UI feature for another project, and by the time I came back to the desktop issue, the solution was suddenly obvious. Not because I got smarter in the meantime — my brain just got a break from that problem without actually stopping work.

Not putting all eggs in one basket

If one project goes quiet for a stretch — waiting a week on client approval, say, or sitting in a testing phase that doesn’t need much active coding — the other projects keep moving. That makes both my work rhythm and my cash flow more stable than depending on a single source of income. I once had a client pause a project for three weeks out of nowhere because of an internal restructuring on their end. If that had been my only project at the time, those three weeks would have been three weeks of zero income.

Side projects become a space to experiment that actually gets reused

Things I learn from one project often get reused in another. The no-backend architecture I use in Istiqomah, for instance, taught me a way of thinking about state management that doesn’t depend on a server — and that came in handy again when I had to optimize an offline-first feature on a client project in a completely different domain. Project variety makes my “experience library” richer than if I just repeated the same patterns in one domain over and over.

But it’s not free

The challenges are real. It needs tighter time management — I now block time per project on a calendar, instead of just working based on mood. Communication with each client about timeline expectations has to be explicit from the start, because “I’m working on several projects at once” can sound like an excuse for being slow if I don’t explain clearly how I prioritize. And context-switching has a real cost — going from a Spring Boot backend architecture mindset to debugging XAML bindings in Avalonia in the same day eats mental energy, not just time.

The key for me: don’t take on more than I can deliver with consistent quality. There was a stretch where I tried holding four projects at once, and that’s the point where quality started slipping — not drastically, but enough that I noticed myself being less careful than usual. I cap it at two or three active projects now. Better to run that many well than many projects done half-heartedly.