Blog of Raivo Laanemets

I was a freelance software developer and consultant for nearly 15 years. In this article I decided to put down the 5 most important approaches that gave me success and the 5 mistakes that burned me out and nearly killed my career.

There are lots of articles written elsewhere on how to be a successful freelancer and to avoid common mistakes. This post is a look back to my own experiences.

I started writing the article with 20 bullet points on both the success and mistakes side, but I found it to go too long, so I first reduced it to 10, and finally to 5.

As said, there are many guides on freelancing. It seems to get pushed a lot nowadays, for some reasons. I have held a full-time corporate job as well. I don't view freelancing as easier or harder, just different. I have mainly worked with distributed teams In the both settings.

In freelancing, you have more control over the job but also more responsibility. In a corporate job, you have less control but more support from colleagues. Freelance software development is more efficient. Corporate software development is more stable. Of course, there are exceptions.

Success

• Helping others.
• Telling stories.
• Communicating through collaborative planning.
• Starting to code early.
• Being ready to learn new technology.

Helping others

I got my first job on Freenode IRC in 2004. Freenode IRC is an online tech-focused chat. I was in the PHP chatroom, discussing various coding problems with other people there. I remember helping out one guy with some image processing code. Later we discussed about PHP and web development in general. He had a company building web sites and decided to offer me project-based work. It turned out pretty well. We built many web sites. It was my first client and first job.

It is about the general mindset of being helpful and serving others. There are lots of people in need of help. Serving others is the most important part of the entrepreneurial mindset. It makes you focus on creating value, not on extracting it. Extracting is important too, for sustainability, but inherently limited to the amount of value created. When you are recognized as being helpful, many opportunities will come alone.

Likewise, it is the mindset that I have been looking for in my clients. The client relationship turns thus into a "helping others helping others" situation. I have selected my clients very carefully and I'm quite pleased with nearly all of my choices.

Telling stories

Telling great stories is the best method for selling anything. When someone, at a business or tech event, asks me what I do, I usually describe myself in the terms of solving my current client's problem. I usually reveal it only later that I'm actually a freelancer.

It's important to listen. Entrepreneurs often want to talk about their businesses. It's a great conversion topic, much better than something generic, such as the current weather. If the conversation partner is your potential client, then this discussion can give a considerable amount of important background information.

If the person is in the need of building some sort of web application, I make my sales pitch. I reveal that I'm a freelancer, give a quick vision of how I would build it, and give supporting story from an earlier project where I did something similar. This story-based approach works extremely well.

Communicating through collaborative planning

I learned a lot about team communication in university courses. We had group assignments in almost every course. This was at the early years of my freelancing career when I studied and worked at the same time.

I remember that on the first courses we were unable to get anything done with the group. Nobody seemed to be motivated to do anything. We barely passed these courses. It was really miserable.

At some time I started to observe other teams and one pattern stood out. The most successful teams were able to divide the assignment goals into simple ones and devise some sort of plan to achieve them. They did it collaboratively in a group session, with nearly everyone enthusiastically proposing ways to do these simple goals. It was not done in isolation by a single person. The subgoals had to be simple, nearly trivial, and everyone had to be included in this.

In later group assignments we tried the same approach. It was so effective, that in any team, where we used this approach, we nailed all group assignments. It does work amazing for anything collaborative where you have to do any planning, including software projects. However, it requires someone to kickstart the process and include others in the planning process. If there is nobody else to do it, it's best to take this initiative yourself as early as possible.

The real-world software projects, where we did this sort of collaborative planning, turned out to be substantially more successful than those, where the communication with the client was mainly one-way, with planning done in isolation without much feedback.

Starting to code early

I have started to code as early as possible in every project. For example, if it's a web application, I usually get authentication working and start developing the user interface as soon as possible. Usually it means static HTML pages which get turned into page templates later. The application is deployed to a test server right away.

It breaks the trust barrier, it shows the client that we mean business. It also gives very fast feedback cycles, especially on the user interface features. All my clients have loved this approach. Some older co-developers have questioned this rushed approach and preferred more technical planning upfront, which I agree with, for more complex systems.

I usually build the user interface first and then come up with a data model to support it. I consider external interfaces, like 3rd party HTTP APIs, to be very important as well.

Sometimes I need to use libraries that use quite specific concepts. This includes advanced graphics packages, special-purpose databases, libraries to read or write specific file formats, etc. Learning these at the early stage of the project is a priority. I like to see some working code, even if it's incomplete. For example, a script to read a single record from the database. It gives me an assuring feeling that the library is any good before building something substantial on top of it.

My general web development stack is very stable, I know what I can do with it. I know it inside-out and can quickly start new projects.

Being ready to learn new technology

I landed one of my best clients by jumping into a desktop project. It required me to learn the C++ language in 2 weeks. I did not learn the whole language but enough to get the prototype built, and to be productive to keep developing it. On the following weeks, I searched for the most efficient ways to get proficent in Qt (the C++ framework we used) and received lots of help from IRC, including important pointers from the Qt core developers. Thankfully, I got the system architecture and design right, so later I only had to refactor the code to common idioms, const qualifiers, and other proper C++ details like these.

In my opinion, it is not a good idea to learn in advance. There are so many technologies, techniques, frameworks and libraries, that learning everything would be impossible. A lot can be learned on-the-fly.

Mistakes

• Not taking a break when needing it most.
• Not having a place to work.
• Confusing responsibilities.
• Taking more responsibilities outside work.
• Not moving on.

Not taking a break when needing it most

Not being able to take a break:

• Destroys your physical and mental health;
• Destroys your relationships with other people.

The idea is to avoid situations where you are forced to work instead of taking a break. There was one particularly bad situation where this happened to me.

In 2015, I had worked really hard on one project and then the client decided that he was not going to pay. It was my old friend. I had made no signed contract with him. Instead of taking a break, I had to work even harder on the following projects to gather some money for living. Not having a signed contract is actually one of the common mistakes in freelancing.

The nature of freelancing makes vacation planning quite hard in general. You cannot easily offload peaks in workload to someone else. There is also a strong pressure from clients who want to manage their projects sporadically and not have a well-defined development cycle. I recommend to avoid such clients. At least, have a "support" type of contract, stating monthly fixed fee for readiness and an hourly rate for the actual work.

Post-launch/release work is frequently underestimated. The real work often starts when the system goes into production. In any case, always demand payment before the launch. In one project I was put under pressure to take on unplanned work after the launch by threats of leaving the pre-launch work unpaid.

Not having a place to work

There must be a place where to do the work, an environment where you are productive. I have not always had such place. Software development, especially programming, requires a quiet environment, where you can work on a problem for hours, without unnecessary interruptions.

It is common for freelancers to work at an home office. Sometimes it is not an option. Not always are there suitable offices available for rent nearby. My home town is very small.

There are cafes and other temporary work places but they are not sustainable. I cannot take my high-end desktop PC to a cafe. Loud conversations with clients disturb other visitors.

It also kills the daily routine. There is already enough unpredictability in freelancing. In my opinion, it should be separate office room at home or a rented office. Cafes are better left for short business meetings.

Confusing responsibilities

Building an information system is very different to operating (hosting) one. Both require a different approach.

It is very important that you and your client understand how the responsibilities in a project are divided. Clients often expect you to also take some operating responsibilities, even when you have a strict contract saying otherwise.

This happened recently to me with one of my high-profile clients, a very powerful organization. I built them an electronic voting system. It required someone very trustworthy to run it. I helped to install it into a server and ran the auditing trace for them. However, some people in the organization leadership did not trust the system and I was put under a severe pressure to prevent its usage. On the other hand, I was threatened by the rest of the organization to run the system. The threats included accusations in criminal behaviour and legal threats with penalties exceeding the project budget 10 to 100 times.

Thankfully, I had a strict contract stating my responsibilities to be development only. This allowed me to walk away from the situation and let the organization sort out its trust issues internally. Even though I was able to walk way, it was one of my most horrific experiences ever.

Taking more responsibilities outside work

In 2015, I took on a volunteer board member position at a large apartment association. I thought that, since I have a flexible work schedule, I can easily help to manage things there. I was very wrong about that.

The apartment association was just founded and ahead of it was a huge reconstruction project to renew the central heating, plumbing, ventilation, and exterior of our buildings. The project was straighforward although it had more than 100 times bigger budget than something I usually worked with.

It took many nights and cans of energy drinks to put together the paperwork for the construction company, loan provider, loan insurance company, state support provider, and other parties.

One of the biggest issues were constant interruptions: phone calls, visitors at home, people stopping you whenever you stepped out the door. It was not possible to solely focus on the construction project: overflowing garbage bins, public area cleaning, and so on, had to be managed as well. I had to do this next to my software development job.

The worst issue was a group of owners who were determined to stop the project in whatever way. The project and the board were attacked in newspapers; our project partners were called in attempt to show the board to be fraudulent. The group did not believe that we did our work voluntarily, without compensation. The project was thought to be a grand scheme to trick the owners to take a huge loan and siphon the money through the construction company to the pockets of the board.

Anyway, we managed to get through all of it and the project was very successful. More than 100 families got much improved living conditions. It affected my software job, for worse. Constant interruptions and context switches between software and construction wore me out. I quit the board job after the project was done but it had already burned me out.

Not moving on

It is important to recognize when to move on.

For the most part of my life, I have been living in a small rural town. Finding any freelance development opportunity is not easy here. Besides a few exceptions, all of my best clients came from either startup or tech events or from my network of friends. I have found no work from online freelance job sites.

Online advertising as a company turned out better but it didn't lead to any work. At a period of time, I pushed my company brand (fancy name, nice logos and well-edited porfolio), but all potential projects were out of scale: multiyear contracts requiring multiple developers. When I told the contacts that it's a one-man company, they all lost interest. Although I knew quite many other developers, I was too afraid of hiring them and ending up with no funds to pay their salaries if none of the big project deals came together. I'm not that much of a risk taker to build a business like that.

Since 2013, after I started blogging, I have received many interesting full-time job offers from well-funded startups. Although it requires focusing on some specific developer role, many of these deals look very good to not be ignored.