Freelancing While Full-Time: Managing Multiple Codebases

For the past few years, I have been freelancing through Yazilimci Bul while working full-time as a senior engineer at Digiturk. I lead a team of five at Digiturk during the day and take on freelance projects during evenings and weekends. It works, but it requires systems, discipline, and honest self-assessment. This post is about how I manage it, what I have learned, and the mistakes I no longer make.

Why Freelance at All

The obvious answer is money, but that is not the main reason. Freelancing keeps me exposed to different tech stacks, different problem domains, and different team cultures. At Digiturk, I work within a specific technology ecosystem and problem space. Freelancing gives me the variety that keeps my skills broad and my perspective fresh.

Building Yazilimci Bul, the developer marketplace, was itself a freelance project that grew into something much larger. The platform now serves over 40,000 members, and maintaining it alongside my full-time role is a constant exercise in prioritization.

There is also a creative satisfaction in building something end-to-end. At a large company, I own a piece of a larger system. As a freelancer, I often own the entire stack -- from database design to deployment. That end-to-end ownership exercises different muscles and keeps me sharp.

The Time Management System

The most common question I get is: how do you find the time? The honest answer is that I do not find time -- I create it through structure and ruthless prioritization.

My weekly schedule is roughly this. Monday through Friday, 9 to 6, is Digiturk time. I am fully present, leading my team, writing code, attending meetings, and doing code reviews. I do not touch freelance work during these hours. It would be unfair to my employer and to my team, and it would eventually degrade the quality of both.

Evenings from 8 to 11 PM are for freelance work, but not every evening. I typically work three to four evenings per week, depending on project deadlines and personal commitments. Saturdays are a half-day of freelance work, usually four to five hours in the morning. Sundays are off -- no code, no email, no Slack messages. This boundary is non-negotiable because burnout is a real risk and it creeps up slowly.

The key to this schedule is preparation. Before each freelance session, I know exactly what I am going to work on. I keep a running list of tasks sorted by priority and estimated time. When I sit down at 8 PM, I do not spend 30 minutes figuring out what to do -- I open the right files and start working immediately.

Managing Context Switches

The hardest part of freelancing while full-time is not the hours -- it is the context switches. Switching between codebases, tech stacks, and problem domains requires mental energy. If I am debugging a complex streaming media issue at Digiturk during the day and then need to switch to building a React dashboard for a freelance client in the evening, my brain needs time to unload one context and load another.

I have developed several strategies for managing this. First, I keep detailed notes. Every time I stop working on a task, I write a brief note about where I left off, what the next step is, and any open questions. These notes take 30 seconds to write and save 15 minutes of re-orientation when I return.

Second, I batch similar work together. If I have multiple freelance tasks that involve React, I schedule them for the same evenings. If I have backend tasks, they go on different evenings. This reduces the cost of context switching because the mental model stays consistent within a session.

Third, I use separate development environments. Each project has its own VS Code workspace with specific extensions, settings, and terminal configurations. Switching workspaces acts as a physical trigger that signals my brain to change context. It sounds trivial, but it works.

Communication and Expectations

Freelancing while full-time only works if you set honest expectations with your freelance clients. I am upfront about my availability from the first conversation. I explain that I work evenings and weekends, that I will not respond to messages during business hours, and that my turnaround time is measured in days, not hours.

Most clients are completely fine with this, especially when the quality of work is high. The ones who need real-time availability or same-day turnaround are not a good fit for my arrangement, and it is better to recognize that upfront than to overpromise and underdeliver.

I communicate primarily through asynchronous channels -- email, project management tools, and recorded video updates. Video updates have been particularly effective. Instead of scheduling a call, I record a five-minute Loom video walking through what I have built, demonstrating the feature, and explaining any decisions I made. Clients love this because they can watch it on their own schedule and share it with their stakeholders.

Technical Systems for Multiple Codebases

Managing multiple codebases requires discipline in organization and tooling. Here is what I use.

Each project lives in its own directory with a consistent structure. I use a naming convention that includes the client name and project name, which makes it easy to find things. Every project has a local README with setup instructions, architecture notes, and credentials references (pointing to a password manager, never stored in plain text).

Git hygiene is critical. I use descriptive branch names, write meaningful commit messages, and never leave work in an uncommitted state. When I close my laptop for the night, every change is committed and pushed. This protects against data loss and makes it easy to pick up where I left off.

Docker has been invaluable for managing different development environments. Each project's dependencies are containerized, which means I never have conflicting database versions, conflicting Node.js versions, or other environment issues. I run the project's Docker Compose file, and everything works.

The Financial Side

Freelancing income provides financial security beyond a salary. It is a second income stream that is independent of any single employer. In Turkey's economic environment, where currency fluctuations and inflation are constant concerns, having income diversification is not a luxury -- it is prudent planning.

I price my freelance work at a premium compared to full-time equivalent rates. This is intentional. My limited availability means I need to be selective about projects, and premium pricing naturally filters for clients who value quality over speed. It also compensates for the opportunity cost of my personal time.

Mistakes I Have Made

I have made every mistake you can imagine. I have taken on too many projects simultaneously, leading to missed deadlines and stress. I have underestimated project scope, leading to evenings that stretched past midnight. I have neglected my health and relationships because I was chasing deadlines.

The biggest mistake was not setting boundaries early enough. For the first year of freelancing, I did not protect my Sundays. I worked seven days a week and felt the effects within months -- reduced focus, lower code quality, and growing resentment toward work I used to enjoy. Implementing a mandatory day off was the single most important change I made.

Another mistake was accepting projects outside my expertise in an attempt to learn new technologies. Learning on a client's dime is unprofessional. Now, I only accept projects where I can deliver at a senior level from day one. If I want to learn something new, I do it on my own time with personal projects.

Is It Worth It

Yes, but not for everyone. Freelancing while full-time requires a specific combination of discipline, time management skills, and genuine enjoyment of the work. If coding in the evening feels like a chore, this arrangement will lead to burnout, not growth.

For me, it works because I genuinely enjoy building things. The variety of projects, the autonomy of freelance work, and the financial benefits make the trade-offs worthwhile. But I am always honest with myself about when to scale back. Some months, I take zero freelance projects because my full-time work is demanding or because I need rest. That flexibility is essential for sustainability.

The key insight is that freelancing while full-time is a marathon, not a sprint. The developers who sustain it long-term are the ones who protect their energy, set honest boundaries, and remember that the goal is a better career, not a busier one.