“What kind of freelancing should I be doing?” That is a question asked far too often with little to no opportunity for answer. Let me help.
Oftentimes, when developers intentionally set out to do freelance work (some of it just falls right in your lap), the first question that comes to mind is, “Where do I find the work?” Once you have a lead, you wonder, “how much should I charge?” You cross that bridge, but now you have to deal with contracts, schedule, client communication, go live, etc. Because you write code for a living, you’re good at building stuff. When you dabble in freelancing, however, there’s a whole new component of the business that you have to manage. This component needs to be understood and managed properly. But in order to do so, you must answer the most important question in freelancing, “What kind of freelancing work works for me?”
The answer to this question is largely based on your specific skill set. To find the answer, let’s first discuss some principals. Applying these principles will all but eliminate the chances of spending months of late nights asking what you got yourself into. Before I started my software consultancy 9 years ago, I did a fair amount of freelancing. I built websites, custom software, pulled cable, did video work, maintained networks and resold hardware. I wasn’t exactly focused, but I’m glad that I was exposed to a wide spectrum of project types as there was much to take away from it all. So now, 18 years after starting, I’ll share what I have learned.
I’m a great developer, what could go wrong?
Before we get into what to do, let’s talk about what not to do. Freelancing on the side isn’t for everyone. Heck, freelancing full-time isn’t either. If you go about it the wrong way, it’s a disaster. Do it right, and there are tons of benefits.
A few regrettable mistakes to avoid:
- Promises were made at the beginning of the week, but some things came up at work or life which made it hard for to deliver them. As a result, the deadline was missed. Now the customer is upset, and the job is no longer worth completing anymore.
- A project comes along that has some things that you have played with before, but there are some items that will require some research. Because the project scope included functionality you’ve never built before, a feeling of uneasiness begins to creep in. That’s a good thing. Until you can “unpack the scope,” you can’t safely say you understand the effort involved in building something. Now, the weekend project has turned into weeks on end of research, troubleshooting, and misery, simply because you got in over your head. And, yeah, you also have an upset customer.
- You know exactly what you are doing, you have refrained from making promises, but this project seems like it will never end. You knew the scope was huge, but not that huge. Eight weeks of working the day job, just to come home to work on the freelance project is killing your personal life. Your desire to finish the project wanes, progress halts, and yeah, you have an unhappy customer.
- You decide to take a 50% deposit and get paid the second half when you finish. The client keeps lording the remaining payment over your head while requesting endless changes. Because they tell you it’s just going to take “one more thing” before it’s perfect, you oblige. This happens 5 more times, and you get mad. You get in an argument with the customer, and they aren’t happy.
Don’t think it won’t happen to you
All of these scenarios have happened to me over the past 18 years, and a simple Google search or scan of reddit will show that others have experienced this as well. The trend with long-running freelance projects (in general, not just for side work), is that there is more room for error.
Work on something you’re really good at, with clearly defined expectations, that will require no more than two weeks for you to complete
What was just described above is a summary of the principles I referred to earlier in the article. Let’s dig deeper into these principles.
Work on something you are really good at
I recommend that whatever you do during the day with great proficiency, you should also do at night. While it may be a temptation to break out of the doldrums of the day job by trying something new with side work, that’s a really bad idea. If you want to do that, experiment with a personal or open source project. The key to doing something you know really well is that it will offer the following:
- Lower stress
- Fewer blindspots, as blindspots can lead to disaster.
- The ability to execute the project in the middle of the living room while watching TV
Predictability in freelancing is even more important than it is in your day job, so do something that you can predict with great confidence.
Clearly define your expectations
This is just a tip for life in general. When expectations are out of whack, things go wrong. This is particularly true when it comes to freelance project work. If you are going to make a promise, then be prepared to keep it. Let your yes be yes and your no be no. Don’t make promises you can’t keep, and be sure about what you are promising.
The old adage “under promise and over deliver” is very true here. The default in the world of freelancing, however, is to do the opposite, and the negative effects that come as a result can lead to a dangerous downward spiral. There will be a huge temptation, as I am sure you have felt at the day job, to promise the world to your clients, especially if you have under delivered on a promise you have made in the past. Don’t fall for it. You will likely have good intentions when you make promises that you ought not make, but you know that they say about good intentions and where they lead.
Start small – something that you are confident you could finish in a week or two
You are getting your feet wet here. The right idea is to start small and scale from there. Even if you fully heed this advice, there will be a bump or two along the way. The smaller the project, the smaller the chance for failure and the greater your chance of your experience being rewarding. We have had a faithful, part-time freelancer on our team since 2010. He’s worked on countless small projects for us and has raked in about $30k over the years. Most of that work has been completed over a weekend or two here and there.
As an aside, it’s best to avoid projects that need to be done immediately. Part of the “under promise, over deliver” formula is to give yourself some buffer time. Even if you are very confident in the work, with clearly defined expectations, and you believe you can get the work done in a week, you have no room for error if it needs to be done in a week. Always give yourself a buffer.
One last thing…One thing at a time
Work on one thing at a time. If you can avoid it, try to avoid having multiple projects going at a single time. Having too much going on at once has been one of the greatest plights of my time in this industry. Keep in mind, I’m saying this as someone who does this full-time. If multiple opportunities come up simultaneously, schedule them one at a time or be willing to walk away. The greatest benefit you have about doing these projects as side work is that you don’t need this money. If you want to do this for any sustainable period of time, you need to pace yourself.
I have just spoon fed you the parameters for your first free-lance project. You will be tempted by projects that fall outside of realm of these principles, but you should proceed with caution. If you have a deal that doesn’t look like this, but you can’t justify turning it away, drop me an email (vic@parablesoft.com) and we can talk through the details.
Stay tuned for the follow-up articles which will help you figure out:
- Where to find the work
- What you should charge
- What to put in your client agreements
- How to avoid making promises you can’t keep
Help me help you
If you have any comments or questions, please sound off in the comments section below.
If you have a deal brewing and need advice, I’m here to help. Comment below or drop me an email.
If you have written code for any length of time, you have probably come across a bug or a piece of code that has given you fits. Sometimes it can be a typo, or some kind of syntax error that you stare at the screen and just don’t see. Other times you’re integrating with an API and it’s just not giving the result you expect. I have personally battled with code like this for hours at a time. It was more common place early on in my career, but it still plagues me every now and again. In the beginning of my career it was usually attributed to a lack of understanding, now it’s usually caused by the stress of trying to juggle priorities or meet a deadline.
We developers can be really bad at wallowing at our desk for 8 straight hours getting lost in the code. Even when we aren’t stuck on anything, following this practice throughout the day will make you more productive. Here is what the break looks like: