As of this writing, I’m one month shy of my fifth anniversary of freelancing. I jumped off the hamster wheel in May 2014, and I jumped off for good. Some people seem to think that running your own business, which is what freelancing is all about, is not for everyone, that you need to be some level of genius to make it in highly competitive domains, especially the ever-popular software industry.
It is definitely a fact that many new businesses tend to die before turning five. But my five-year-old business is alive and kicking (ass)!
It is not just quick typing fingers that make you the money; there’s much more to it than that. In fact, I’d say that the technical bits are the easiest for technical guys like me, as that’s what we’re good at. But how do you satisfy your client and make money for yourself at the same time?
In the following story, I demonstrate how it is not at all impossible to earn $1,000 per day as a software developer (at least, occasionally). I will also list the factors that work for me in order to do it. I hope this helps you get organized and started on a productive path to becoming a freelance software developer rock star.
Being the busy guy
When I was taking trips to nearby startup hubs, mostly in Singapore and Kuala Lumpur, attending various events to make good contacts, several businessmen started asking about the money-making side of freelancing. These were people who could easily pay other people’s salaries for a year or two but wanted to start something they found interesting and profitable. Many offered interesting opportunities. Typically, people are after my turnkey CTO-as-a-service offering.
Some of the Singaporean high-end shared office spaces with a beautiful view. And I don’t mean the river! 😛
One question I got was about how I manage to balance doing work on startups that might not bring me any direct cash (I get offered revenue share or equity instead) versus doing freelance projects that are fully paid. This is a completely valid question. A man’s gotta live, and living is not free, especially for a family man.
From the client’s perspective, hiring a freelancer who can do the work with maximum focus guarantees the best results. Some people have trouble with split focus, which can especially happen to those who have more work on their hands than time.
Often, the freelancers who can dedicate all their time to a single project are the ones who have nothing else to do. That’s one of the main lessons of Freelancing 101. All in all, it’s far better to be the busy one than the other guy. Then the choice is up to you.
It’s about balance
I gave those businessmen a simple calculation, but before I get to that, here’s my background. I’ve set up a base in Penang Island, Malaysia. Who wouldn’t? It’s a paradise in many senses of the word, not the least for culinary reasons. Regarding living costs, the absolute minimum income that one needs for living here is not very much at all.
Earning just a few thousand dollars a month would not get me into (very much) trouble. Any more would leave me free to try out investments, traveling, or other fun stuff. Mere survival around here is not a big challenge for any competent freelance professional who has a global clientele.
Of course, living on minimum income is not a very fun life, so that cannot be the aim of any freelancer, and downshifting is simply not my thing. (“Upshifting” might be if that was a word!) But basically, living on savings for a time is not a big challenge. For example, setting up a technical baseline for a startup might take two to three months.
On the other hand, if you end up having a monthly income close to zero for any period of time, regardless of how well you were doing, you might not get a new income stream flowing the day you go broke. Reasonable caution and preventive calculations are needed. Having several months’ spending in your pocket for rainy days is not a bad idea.
So, surviving financially is not very hard in Malaysia. And best of all, good food is cheap! But it’s an entirely different case if your base costs are very high. Let’s say you have a big house loan, kids’ private education fees, expensive hobbies, plenty of holidays every year, and so on. In that situation, the numbers I mentioned might need to be doubled or tripled, and you couldn’t even call yourself rich yet.
Super-spicy Tom Yam soup serving battle: in a coconut vs. ordinary bowl. Won’t cost even US$3 in total.
I know a very good experienced freelancer who had the same model as me. Freelancing brought in the cash and still left plenty of time for unpaid startup hustle. Unfortunately, he had to cancel a very good equity-based startup deal because of a sudden change in his life situation that produced new monthly costs.
The rational thing to do, of course, was to cancel everything not bringing in direct cash, and keep doing what he was good at. A big opportunity was lost, obviously, but his family’s finances were secured, which makes sense.
Time = money
Now, back to the calculation that I told those businessmen. My principle is very simple: If I can turn my time into money at a high daily rate (or hourly, weekly, or whatever), then it should not take much effort to maintain a positive balance between solid income from paid freelance projects and unpaid time.
Please note that I never separate work time, family time, private time, etc. because all time is just time, which is infinite in theory but limited in terms of a human lifetime, whereas results are finite. Imagine the best possible result first, then only think about the time span.
Time will pass regardless of what I do, so the time I spend on getting great results is all that matters. Spending time without the hope of delivering the best stuff is not a reasonable option. (Working from a home office makes all transitions really fast and easy. Once I finish a task, 30 seconds later, I’m at lunch, and 15 minutes later, I’m back at full speed.)
Thinking like this helps in getting multiple things finished and paid for without losing focus on precious long-term unpaid projects. My aim has been to work a maximum of one week a month for
covering all my family’s mandatory expenses. How intense that week is can vary a lot. And this model obviously does not fully match with long-term involvement in most projects, so that one week might become two and be split over the entire month — half a week here, half a week there — so there will be some fragmentation. But the baseline is the idea of dividing the work up in one month’s time:
- The first week is for cash.
- The second week is for safety.
- The third and fourth weeks are for the future.
The second week is practical for keeping a safe margin and swapping between intense months of paid projects and unpaid ventures. The most fun part, obviously, is those third and fourth weeks that I can spend on things that don’t bring cash.
These are often my own experiments on various product ideas, if not someone else’s ventures that I support as a co-founder or technical expert. This principle gives me plenty of flexibility for other things, and I have learned to appreciate it.
I demonstrated this principle in a simple project I did not long ago. I’ve started using this as an example of my ludicrous speed, like in the sci-fi classic “Spaceballs.” The difference is, my brains do not go into my feet! They stay exactly where they should — at least, most of the time!
“What have I done?!?! My brains are going into my feet!!!”
public ProjectPlan InitProject(Client superAmbitiousClient)
Ok, let’s then go through what actually happened when I did the project.
I got a contact request from someone working on a topic not far from my own Ph.D. thesis work. They were looking for someone to code an augmented reality demo using Microsoft Kinect for Xbox One. That’s exactly what my specialty is from the coding side, which was why this guy found me in the first place.
In short, I would need to make a preliminary demo version of a new Kinect game for my client to be a crucial part of his short-term plan. If we succeeded and managed to work well together, I could also support the long-term plan. From the beginning, I got the impression that my client had high ambitions and would aim to win competitions in his domain if we reached great results in the first steps of the project.
As we started planning the project, it turned out that we would both be in Kuala Lumpur (henceforth referred to as KL) in the same week. It was a place I passed by often, so it didn’t even take any extra effort to arrange a meeting there. We went for lunch and talked over the project, and I got a pretty good understanding of what the real need was.
Also, as I always do before starting, I asked which parts of the project he knew were certain and which were uncertain. This approach is useful for building the right expectations and setting limitations on what I can offer. It’s almost like an interview, and if done in a nice way, it helps a lot in getting the most important part of the project to reach fantastic results. The target has to be clear. And in this case, it worked perfectly for both of us!
Here is the timeline. Getting started always takes time, and I don’t mind delays in calendar time, as I am typically 100-percent booked from previous projects.
The project timeline
Day 1, Thursday: First call with the client. I listened to my client’s needs, and we talked about the scope of the project. I learned the aim of the project and offered additional consultancy support on top of the technical work that I would do. It also turned out we could meet in person.
Day 12, Monday: Lunch meeting in KL. I learned about the academic aims, which also affected the timeline of the technical parts, and we sketched up a rough timeline for his entire long-term project. If the overall project failed in the beginning, the technical bits that I’d make wouldn’t really help that much. General advice regarding the whole process was what extra I could bring to the table.
The immediate thing for the client was to wrap up previous things, which would take over a week.
Some cute sites I often pass by in Kuala Lumpur. Something old and something new.
Day 23, Tuesday: Short call with the client. With a full understanding of the technical part that I’d need to deliver, I explained all the limitations that we would face so there wouldn’t be any behavior on the screen that looked unnatural while the system ran complicated pose and gesture recognition algorithms as intended. I listed all tradeoffs with their implications.
At this point, my client mentioned that there was a competition he was aiming to participate in — next week! We had exactly seven calendar days to finish everything! The timespan at this point in time turned out to be way tighter than I had assumed.
Since I really like working with ambitious result-oriented guys, I’d of course do my best to deliver something extraordinary, but I’d better be really fast. But there would be no room for mistakes. The thing is, good and fast is rarely cheap. Luckily, this didn’t seem to be a problem for my client.
Day 24, Wednesday: Official start of the project in the evening, which meant my 50-percent advance fee was paid. I’d have to have the whole thing finished by Monday morning; otherwise, there would not be any margin for even minor improvements before my client’s competition on Wednesday. He’d be spending the whole of Tuesday traveling to the venue. Best case: I’d have something ready on Sunday for the first round of testing. This timeline worked for him.
Day 25, Thursday: The first coding day. By chance, it was a day that I had my internet connection upgraded, so I lost the morning on supporting the installation (in Malaysia, this kind of process is far from “plug and play,” one of the few bad sides of living here). I spent the afternoon getting my previous project (not involving Kinect) wrapped up, but something was still left for tomorrow.
After dinner, I got started on the new project. I made the base framework for the software with all core components defined in terms of how they would look on screen. The user interface (UI) was something I expected comments on. After four-and-a-half hours of ferocious code structuring and UI coding, I had a screenshot of the software for the client to review. The client said, “Perfect.” I only changed one small detail.
Day 26, Friday: I spent half an hour in the morning working on editing media content. The normal 9 a.m. to 5 p.m. workday was actually spent on my previous project, to make sure I would have maximum focus on the new project for the next few days.
(Yes, this means that I don’t take weekends free if there is something critical to do. You can never sacrifice old projects in favor of new ones if you appreciate all your clients and wish to work with them again in the future.)
Again, I spent three hours in the evening working on the Kinect project’s toughest bits from a performance perspective. This is a good thing to do in the beginning so you know how much time you have left for detailing and fine-tuning, which are not always critical to the overall delivery. The main points need to work perfectly, especially in this case, where the scope was just a demo version of a new Kinect game.
Day 27, Saturday: I slept in to gather energy, and I spent six highly efficient hours developing the core gesture and pose recognition bits. This process tends to take a few iterations to get them right. With Kinect, you can always write the code recognizing the same pose in a dozen ways. Most of the time, you just need to find the best one by intensive testing.
During this Saturday, I managed to make sketches of all unique poses and divided them into code blocks that I could easily change upon feedback. Efficiency is the key and the ability to block distractions is paramount. In the evening, I had to follow up with communications about my previous project and minor other emailing/messaging. Then, I had a nice family dinner.
An efficient method for blocking all distractions: immersive virtual reality. Works only when developing that type of software, though.
Day 28, Sunday: I started early, at 6 a.m. As I’m the complete opposite of a morning person, this was an achievement on its own! But on tight deadlines, it is better for me to stretch from the morning, not the evening, as I tend to have ideas in my mind right after waking up. At 8 a.m. I finished all the core features and the user interface. The only thing left was the never-ending fine-tuning process.
Out of the dozens of ways to code the same pose recognition feature, you have to be able to pick out the best one. This part is usually quite simple in terms of the number of code lines, but it takes a lot of testing. And that can mean a lot of exercise! Change a few code lines, get up from the chair, run through the program doing whatever movements you are supposed to do in front of the sensor,
and observe the system’s behavior. Get back to the chair and repeat. Try many different variations of the code, as well as your own movements while testing. This can get heavy when you do several long days in a row, but at least you’re not sitting all day (and night).
By 6 p.m., just in time for dinner, I was pretty much done. My client was ready to test straight away and accepted the results for now. “Perfect” again! He’d have more ideas for improvement after trying it out with his other team members on Monday. So, I managed to sleep in peace. I logged 11 super-efficient hours for the day.
Day 29, Monday: My client had done more testing with his team, and they had questions on the specifics of the implementation, which took time to bounce back and forth. We also decided to revise small bits of the UI, which I had hoped to be given in the beginning, as it was the first delivery.
But this kind of highly interactive game often requires personal experience instead of just looking at static images to get the right impression. It’s not just about the beauty — interactivity is the king. Three hours were spent on iteration, which is below the percentage I was expecting. I had still a full day left for working on my previous project, which was a pleasant surprise to everyone, including myself.
Day 30, Tuesday: My client took most of the day to travel to the competition venue and set up his booth. I worked exclusively on my previous project, which needed a great deal of attention, as I had skipped a few days and there was a minor deadline at the end of the day. This was perfectly synced from the beginning.
Day 31, Wednesday: I slept extra hours to catch up on sleep. The lag wasn’t there because I was constantly coding something, but rather because I was preparing and revising all the features in my mind, reflecting if I had a bug somewhere and other such mental exercises.
On this day, I did all the other minor things that I had pushed aside from the weekend. I called my Ph.D. student in Finland to check on his progress. (This academic adviser job usually takes one to three hours of my time.) Then I took another call from an old client and agreed to start a new quick project for them the following week. I updated my website, which was something I had already postponed for months. It required no coding at all, which balanced things nicely.
Then in the evening, my client called. He had nailed the competition and got his award! This news totally made my day — or more like my whole week. And my client sounded like the happiest man on Earth! There’s no better feeling than working hard to make something rather complicated work really well and make a client this happy.
A few days later, the client cleared the bill and we concluded the project officially. We proceeded with the long-term plan, and I ended up supporting his project in various ways for the next year and a half.
Money = time
In the above timeline, I mentioned the exact hours spent. I logged them on purpose despite the fact that this was a $3,000 fixed price project, my client’s preference for initial stage work. I wanted to measure my performance and see how close to the estimate I got. The period was from Thursday night to Monday morning while juggling other things around, so two evenings, two full days, and one morning, with 27.5 hours being the total.
My estimate was 30-35 hours. That made for $109 per hour, and the total sum was something that easily covered all my expenses for a month. A complete project done from scratch with unique pose recognition algorithms and a simple user interface and the whole package was nailed in less than one workweek. With no other jobs on my table, this could have been done in just three days!
But did I really spend that much time preparing the project? Yes! I met the guy in person (and filled my stomach with great food, which he paid for), and I did some emailing, which is part of all project work and customer relationship management. I might have spent the same time talking with old clients about new potential collaborations.
Fostering good contacts is crucial for freelancers and part of the lifestyle since you are your business. I did all the planning and risk analysis (while jogging around my neighborhood, which I do anyway), though this is the part that is hard to quantify — typical to any modern knowledge worker, I suppose.
One of the nicest pass-by spots when carefully executing my jogging/planning routine. This kind of scene can make you think there really is a chest of gold at the end of the rainbow just for you.
So, I spent time on planning and preparations, but did I really lose time for doing all that vs. the time I would have spent on something else? No, not really. The basic principle is to combine activities that need to be done anyway with project preparations. It’s the part that makes execution both quick and flawless.
How to achieve “ludicrous speed” that brings $1000 per day
So, what is the secret behind my “ludicrous speed” software development?
- Prepare to understand your client’s priorities. This is often more iterative than in the example above.
- Think through all activities that you need to do before starting (perhaps while exercising). For me, as a fully formed plan sticks in my mind with all dependencies understood, I rarely use an Excel sheet for this (unless I have to share it with my client). Typing is slow, thinking is fast.
- Map all uncertainties and book time for dealing with them as their natures reveal themselves.
- Think through all the technical parts you have to develop (I rarely document them, unless my client wishes me to).
- Communicate with the client to explain what needs to be done. Some of that may be on the client’s side. Some need visuals, such as UI screenshots.
- Book the time for conducting all activities (which means the family needs to be supportive). And if possible, leave a little extra time to be safe. In my example, I still had almost a full day’s margin!
- Eliminate all distractions before the deadline.
- Execute with utmost care and 100-percent focus to make sure there are no mistakes. Personally, I never rush. This might be counter-intuitive, but as a seasoned programmer, I know how much time you can lose for not writing all code in a good way (though sometimes, adding quick and dirty features is acceptable if they are unimportant parts and if speed is the key to success). I don’t even have a separate bug fixing process nowadays. This only works if the focus is 100 percent — no other thoughts should cross your mind until the finish. (By the way, minor routine tasks don’t count as interruptions if they are just pure execution kind of things.)
- Once finished, take a well-earned break, reset, and rest! And catch up on all the things you missed.
Hiking up Penang Hill for this view is a great way to relax and reset (mentally, not physically!) on free days.
So, this is how I do it and now you know. It’s not that big of a secret! On top of the things I consciously and consistently do, there are personal qualities, experience, and skills that help, of course. I could list a few of those things too … but that’s another story for another time.
