Freelancing can sometimes be a bit of a jungle, especially if you’re just starting out and want to get good reviews or actually have some projects for your portfolio. This might mean taking any and every job that pays even if it is at the cost of your sanity. So I’ve gathered some lessons from one of my recent freelance adventures to perhaps make your freelance experience a little less painful.
I’ve been freelancing for almost 2 years now doing small projects for a long time client with occasional other projects next to my university studies. At the time of this adventure, I was learning python and wanted to get some experience with it. Plus I needed money and so it seemed like the perfect idea to find a job for a python project. The next couple of days were spent applying to anything python related on Upwork that I could sort of see myself doing, even if I hadn’t done anything like it before. Then I got a bite, somebody had a cool project that he wanted to do and he was willing to pay me $50 for it. To a student like me that sounded like a decent amount of money for the work he specified. So we both agreed to work together and I started looking into what he actually wanted me to do. Which leads me to:
Before agreeing to work with a client, try to scope out the project. Look at the requirements and imagine what tools you’d need, what you need to learn and what might cause you difficulty. This can give you both a better idea of what you need to make and how long it might take. It also allows you to reflect on whether the project is feasible for you to take on given your existing schedule and what the value of the project is. With a solid idea of the work required you can better negotiate a price with your client and give an educated estimate of how long it will take you.
The client and I agreed on some milestones where each would be worth $5 and I got a list of requirements for each one. I was sent the framework I would be working with and the existing code I would be extending. Happy days. I got to work and the first milestone done in a day. The next one took me a week as it was much more time consuming and the third even longer. By the time I had finished the fourth and the fifth milestone, I had spent almost three weeks longer than I had planned to. And so:
After agreeing to work with a client, sit down and have chat with them. Make a roadmap for what is to be delivered when and use your previous research to give estimation of how long it will take. Then you stick to it as well as you can and be open and honest with your client if your veer off track. Also your client might come with additional features or want some functionality, but it wasn’t explicitly stated in the initial agreement. It might be subtle things like “There should be two buttons with this and this functionality” or anything that sounds like something you’ve already agreed on, but when you look back in the requirements it’s not there. Of course it’s not black or white, but just be aware. If anything kindly say that it’s not in the requirements and maybe it can be additional features you can add after the project is done for another fee. Make sure you’re not doing twice the amount of work than you agreed to.
At this point in time both the client and I were frustrated, to the point where I started to dread replying to his messages and he would see my messages and not reply until a few days after. The time difference played a role here as well, as he was 5 hours behind me which meant the only time we could really talk was in the evening when I was “done” with work for the day and he was just getting started.
Beware of time difference, depending on the work you’re doing, not being able to get feedback within a reasonable amount of time is frustrating at best and deliberating at worst. It can also lead to you having to be on the job when you have checked out for the day. Especially if you’ve given them your phone number and communicate over something like WhatsApp. At times for me this felt like I couldn’t reply to my friends without also dealing with my client as I would show up as online. So if this is the case, I suggest setting clear expectations about when you both are available to discuss the project or give feedback, so neither of you end up sacrificing your free time for unfinished business. You could also schedule specific progress meetings to really draw up some boundaries.
This lesson leads directly to the next one:
You probably guessed it would be on this list at one point, but Communication Is Key. Let your client know how you’re doing, if you’re having problems or any issues regarding the requirements. No spamming of course but it’s important to be on the same page, especially down the line when the project is starting to come together. Your view and their view might be completely different and you might end up building something that wasn’t what they imagined or wanted.
By the time I was at milestone 5, I was completely done with this project, sadly only mentally. I had put in so much time and effort, worth much more than I would get paid for it and I could no longer justify it with “at least I’m learning something new”. So when the end was in sight, I thought it would only be one or two days more to finish it, but as it turned out no. Because one thing is having the project on my laptop (in my case, code) and another one is having to deploy it to another computer. Then on top of that having to instruct someone who had never done anything like it before to set it up, when I didn’t really know how to do it myself. Which leads me to:
Before starting or at least getting into the project, think about how to hand it over. This might be most applicable to software projects, but in that case it is important. It’s worthless if your client can’t actually use what you’ve made because it doesn’t run on their machine or there are some issues that didn’t show up when you had it on yours. So anticipate these kinds of issues and try to make it so your project is easy to install. Also factor in time for hand over when you start your project and discuss with your client what their expectations are. Another note, if you’re building software, figure out what kind of environment the software will run in. As it turned out for me, my client lived somewhere that had frequent power-outs and so the software should be able to deal with that. These are the kinds of things you would want to know before starting, not when you think you’re done.
As it turned out with this project, we were both so done that we decided to call the quits. It was so bittersweet for me, because I had wanted to do a good job, but I ended up being way in over my head to the point where it was stressing me out and I was just happy it was over. So the last lesson:
When you start the project take some time to think about under what conditions you’re going to stop, ask for more money or more time. IWrite down backstops, i.e. points you could get to where you stop and backtrack or reflect. So for example if you’re more than 5 days off target, the backstop could be scheduling a chat with your client to let them know what’s up and what the solution might be. Or if your client is refusing to cooperate and keep adding requirements they thought were obvious, you renegotiate or pull out of the project. There are many kinds of backstops and I think if you decide beforehand under which conditions you stop or charge more, you can save yourself some headaches down the road.
There you have it, some lessons I learned from one of my failed freelance adventures. I hope they can help someone else out there and I would love to hear about similar experiences and how you handled it.
Thank you for reading and most importantly, don’t sell your soul!