We software developers are a strange breed of man. We, the instantiations of homo technologicus, love technology. Sometimes all too much! I remember when I started as a 22-year old software engineer at Sysart in Finland. (By the way, check out www.sysart.fi, those guys have scaled up in style!) I was not comfortable at going out to the customer sites even to do simple installation jobs. Why would I, I was just a software engineer? I developed the product; that’s it.

Other guys, the business guys, should take care of everything that had something to do with customers, I thought then. When you work in a company, there’s nothing wrong with this picture when the work is divided in a meaningful way between different individuals of different skillset. It’s called a well-functioning organization. Maybe you, the reader, might be doing precisely that right now.

However, when you turn freelancer, you must trash this kind of thinking or what you get to trash is your dream of freelancing! Either way works, of course, but I’m just hoping you are conscious about your pick. How to freelance as software developer actually depends more on your people skills, as you will see.

Changing the job scope, changing the mindset

If you’ve worked in a large company before, you’ll see the difference immediately. It’s slightly less shocking if you’ve experienced software development in small teams first. The job of a freelance software developer is almost opposite to that of a corporate developer. Coding is just one part, but not the only part.

Still a big part in terms of work hours, usually, but in terms of importance to the customer and significance to your own freelance business, it’s an entirely different story! Unfortunately, most devs don’t ever come to understand this correctly.

When turning freelance, your days of being an ordinary software dev are over, as you will soon learn.

Freelancing as a software developer is very much a people job, strange enough. When I started freelancing, I didn’t think like this. But it got clear very quickly.

Let’s start by going through my personal example from my Year 1.

“I’ll just code my way to success and glory!”

When starting to freelance, what does a developer do? Develop something, of course! I did exactly that. I had one well-paid project, to begin with, so I just needed to find the second one. Project or product, I didn’t really have a clear idea yet, so I tried to develop something cool for other developers since that is what I knew best.

It was a natural thing to do. I already had specialized heavily in AR and VR, so I thought of making a product that helps to develop some of the applications in that space. All the planning, algorithm development, and coding were enjoyable, and I thought I was making something genuinely fantastic here.

I never sold a single license. I never even finished it properly. It didn’t take that long for me to realize that what I was doing would not bring me any more paying customers than sitting on my butt watching movies. When I started making calculations about cash flow, I just couldn’t see a way to find customers for my little product even to pay for the time I had spent making it, not speaking of making an actual profit.

Hundreds of people would need to buy what I had made, but my product was simply too specific. Since I wasn’t a businessman, I somehow failed to see the business side of things completely – simply because I loved coding!

My first product idea wasn’t this bad, but it got pretty close!

(Instead, eventually, a big part of the product became a crucial component of a client project I did for over two years in a part-time mode much later, ultimately resulting in a robust patent application that founded the technical development of my client’s company. So, in a sense, the effort was not wasted at all, and I kind of sold it, but just once, and years later.)

What did bring the paying customers were two activities: 1) I established a consistent online presence, and 2) went out to hunt the customers IRL. I realized Gandalf was right all along! 🙂

The customers are out there too! Don’t get too comfy in your comfy chair which effectively prohibits you from going out there to meet them. Better to learn how to reject your own excuses.

Establishing a minimal online presence

The first part was easy, of course, being a sort of development task. I made a website to introduce my new business and portray my relevant experience. Portfolio I didn’t have yet, because of having only corporate and academic backgrounds.

My plan was very elementary as I didn’t know (or care!) about sales funnels or anything like that. Any person I’d get hold of would get a business card that includes a link to my website which helps to demonstrate all the skills and experience I had. The plan was a no-brainer.

As for the content, I didn’t have anything to show as a freelancer, yet. The only concrete thing I could include on the website was short projects on a page called Read more about my Background. I decided to keep listing things rather than focusing on one, the best, content, which was a video from my previous job on YouTube that I could show to prospective clients upon the start of the discussion, as I planned then.

I was 36 then with a long career-rocket history which was the main point I tried to highlight. Speed and quality making a positive impact. I suppose the first version of my website was mostly an online CV with illustrations, only. 🙂

Going “out there”

The second part was a lot more work. I activated all of my old contacts that I suspected needing some help with software development, just to make sure I had exposure. I went for catch-up coffee with lots of people and landed a couple of engagements quicker than I thought.

One of them was my first CTO-as-a-Service gig for a web development company that required temporary help when shuffling their organization. Please note, nothing to do with AR or VR, but that project was perfectly aligned from the activity perspective with what I tried to do. Interestingly enough, the person who hired me was a person who tried to hire me years earlier! Going for such clients seems pretty obvious now, but I didn’t think of it then. 🙂

Another project that I landed was a supporting role in a well-funded research study, which was a perfect alignment with another part of the offering I planned from the beginning. The easiest part, given my background.

The whole attempt of trying to execute a sales process felt peculiar at first. I felt like the worst salesman who had nothing tangible to sell. I could only offer my time and skills. It was a very educational experience in the sense that although I knew I had an extensive network of people who might need my services, I didn’t really think of an efficient way to get projects started in real. I didn’t even count the number of meetings I did (but the local coffee shops probably counted their profits because of my meetings … and I didn’t mind since those days I needed to drink a lot of coffee anyway, haha).

To make business, think of customers

So I didn’t have a sales process when I started. Initially, I didn’t even think I’d need one! Why would I, I was just doing freelance? Later on, that felt pretty stupid and I developed my sales process, and things worked out better than I ever hoped. But that’s another story. The point here is that we devs don’t think of selling. We only think of making things; that’s what we do. Selling is not even a thought process in our minds.

But to start freelancing in a way that brings more than $0 revenue to your little one-person business, you’re going to need a sales process. An easy way to do that is to think your profession through from the perspective of other people, those who you think should buy from you.

You can start by asking yourself these questions in this exact order so that you can specify a subset of the people you have to target:

1. What do you make for other people, which is critical to their businesses?
2. Who are the people who need what you make?
3. Who of those people need your services right now?
4. How can you reach those people?
5. Why must those people buy from you instead of others like you? Why are you their best option?

This kind of thinking can get the development of your sales process started. They are the basic things about the business development of any kind. It’s not so much work, actually, but the mindset of making things needs to be trashed for a moment.

You can think of your intended customer base as a set of characteristics of your dream client. Once that gets clear, try to find them, try to reach them, and try to talk with them. If you’re still not landing any projects at all, it is possible that your dream client does not exist! The other, more likely explanation is that your process is not yet complete.

People who have a background in customer service of any kind beat us 10-0 in this game. Your challenge is to raise your game to 5-5, or at least fair 7-3 for starters. The only way you can deliver exceptional projects to your clients is to understand who they are and what they really want. Only part of it can be delivered with software development methods.

Sometimes it is not even enough to follow orders and take care of fulfilling all the requirements given to you, because the background of the client tells more than the requirements listed. You cannot burden your client with an excessive amount of communication (especially, you cannot ask their opinions on every possible detail), nor can you assume too much and deliver a project that only hits the target partially. It’s about finding a good balance.

The trick to finding clients is to think of the people, those exact persons you already know, who would like to buy from you, if only they knew you existed in their business domain. Then, for reaching out to them there are a number of methods available to you, which you can learn on your own with a little trial and error if not wanting to learn directly from someone else.

If you feel like an alien when trying to sell your freelancing services, you’re not alone. Some people are natural salesmen. Most of us devs – not.

The client’s perception

If the previous point helped to transform your mind from coding to business development, the next one helps you to understand the client’s general understanding of us devs.

I’ll give you another personal example.

This is an actual conversation with someone non-technical who was interested in my CTO-as-a-Service for developing a new AR product for his non-technical domain. The discussion started as usual, and we engaged in the planning phase and talked about the business plan, the product idea, and the project management approach to scope up the initial work to be done in the project.

As a side track of the discussion, there was a question “Hey Mike, do you also make mobile apps or know someone good who does?” because the client saw a collaboration opportunity beyond the immediate project scope, and it looked to me that there were some bad experiences with a number of devs earlier.

My answer was quite direct as I had no intention of doing anything so generic since we were already on the AR track in the discussion (not only would it have been very boring but it would also have side-trailed my other plans at that moment the next several months since this project was not in the execution mode yet).

I said that “about a million people do those things, plenty to choose from,” in a way that it was apparent I was pointing my client to go to the online forum where we first met. The reply was astonishing: “Sure and 999,999 of them are rubbish!” That made me think what the hell we devs were doing wrong! (Also, that made me write this article, obviously.)

That one sentence really made me contemplate. Is my client hinting that I’m the one-in-a-million software developer? Am I really? Probably not, but it looks like some people think so, and I think I know the reason for it.

If clients think only one in a million of us developers are good, shouldn’t we all just quit and invest in the national lottery to maximize our chances of getting $$$?

The nature of devs (or at least of most of us)

The tech part is the natural part for us. We love working with tech; we think tech. It’s the working-with-fellow-humans part that gets us in trouble if anything. We’d need to evaluate like a human, not like a computer. It can be surprisingly hard, and I’m sorry to say. We are forced to think about what situation the other human, the client, is in, and listen carefully. Then and only then do we have a fair chance of success.

I don’t know the situation of this particular client in detail or what experiences he might have had. I developed a hypothesis, though. If a non-technical client is trying to get a technical freelancer to understand what he’s trying to achieve, the process can be frustrating on both sides since the thoughts are not matching on any level.

The client wants an app for business reason X, whereas the dev is keen on listing features that are cool to code. Or the great features suggested by the dev have absolutely no relevance to the client whose business is not improved by it at all, thus it is seen as an unnecessary cost item only.

If the clients see us as technical guys who do technical things without caring about the client, the client’s business, the client’s overall success, then why (the hell!) would they buy from us? The human touch has to be present in the initial discussions, in the project planning phase, and everywhere else until the job is done. Also, no harm is done if keeping it up later on, too, in the hope of a follow-up project.

Be human, clearly human. It helps. Bring your face, competence, and personality into play in all communications with the client.

Problem – solution

Freelancing is about solving your customer’s problems. Often, part of the problem is not technical at all, yet you’re the only guy who can provide a complete solution because there is a significant technical dependency built in the project. Some clients have a clear idea about what they want you to develop. Some have no clue at all.

In both cases, you would need to understand the business side of things too. How does an app that you make for your clients improve their business? Who are your client’s customers? Looking at the big picture helps a lot in filling the gaps in specs, guessing which feature to develop first if you’re given the choice, and so on.

Also, a good understanding of the big picture has a significant technical impact on the project result as well as the process. You cannot miss this part; you will do so if you only think about the code!

The human touch part is the one that helps us to stand out from the masses in the right way. How could you avoid being one of those “999,999 rubbish” developers? Again, it’s definitely not about the code. If you work with non-technical clients, they don’t even know if the code is good, almost good, or just about holding water. Of course, bugs are not tolerated, so it is always a little bit about the code.

Let’s assume there are indeed 999,999 developers who have the same technical skills as you have. There is no way to win clients by coding better than the others once you reach the level of quality that your client doesn’t perceive the technical issues you might have. It is evident that it’s the secondary skills that make the difference in getting clients and keeping them happy.

Understanding the client’s overall problem, discussing (and improving!) requirements, securing a fair business deal for them and for yourself at the same time … these secondary skills are the only things left for you to improve in! Coming from a technical background, that is your first and most important task on your personal development plan.

It’s not about the code. It’s a people job!

If this is how you appear to clients in a crowd of other freelancers, it’s better to give up freelancing. How many clients could you get anyway?

Well, appearing like this is not much better.

One unfair advantage we devs have is that we are natural problem-solvers. We’re just wired to solve only one side of the overall problem, that’s all. Given that the ability to solve the technical problems won’t diminish if doing other things for a while, all we actually need to do is to retarget our problem-solving ability to the human side of doing business with other people.

An example of how I do it: a short ten-minute phone call with a new client who wants some fabulous AR app for an expensive high-end device that I specialize in developing software for. Usually, I do research on the client before starting the call, but this time the info I could google was less than usual.

All I saw was my client’s website and a three-step plan of what to develop as a bullet list in a short introduction message requesting a call about a project I could do for her: a very small proof-of-concept, working prototype, and then a product. In short, the usual process that matches perfectly with my CTO-as-a-Service offering is what the client was probably expecting.

The client had seen my websites and online profile already, so I did not need to explain my relevant background at all.

If I summarize it briefly, this is how it went:

1. The first few minutes were spent on just small talk and laughing about how different the sunny weather in Malaysia was, compared to the client’s country: “Another day in paradise!” (Side note: it wasn’t a monsoon season then, heheh!)
2. The client moved to the topic very quickly, asking about what I could do to realize his high-level plan (which was barely enough to start discussing). I relayed her own plan back to her to make sure she knew I understood it and I asked a few small questions about the intended customer base and intended end-users of the app.
3. I asked about her experiences with the AR device, which turned out to be minimal … but she had tried it a few times and thought that her fabulous new app idea was a perfect match with it. I’m always the realistic guy and prefer to bring this perspective upfront in every discussion. The business case she explained was credible, in my opinion, so I didn’t raise many questions at this point. It was obvious that the app idea would solve one problem the client’s customers had. So far, so good!
4. Beforehand, I already had thought of an apparent technical risk in the proposed project. Perhaps there was a misconception in the client’s mind about the device’s effective range, which would be the most critical technical characteristic in this use case. I advised her to get her hands on the actual device (it costs thousands so I recommended borrowing or rent one) and test if the device’s capability fits the exact purpose. The test could be done without developing any new software for it, using existing materials she already had.
5. The client thought that it was a good thing to test first and agreed to organize it. I made sure she understood that the test result might impact the choice of the device in the first place and would have an immediate impact on the project budget. Also, the app’s price to her customers would depend on the device used, of course.
6. We concluded the call by agreeing that once she completed the test, she’d get back to me with more details on the project plan.

That’s it; I knew I nailed it in about ten minutes! (Actually, most of my initial discussions go along the same track, and when drafting this story in May 2019, I had two similar calls about different technologies and app ideas in the same week.)

See what I did there? What I managed to do was, I

• created a friendly and open atmosphere for discussion (yes, by small talk! in this case, minimal conversation, since it was kept very short). Laughing always breaks the ice, LOL! 🙂
• suggested a way forward (the test plan) on a perfectly logical path.
• improved the idea of my client in a way that reduced the initial cost of the project (she didn’t need to buy the wrong device).
• demonstrated my technical knowledge, which had an immediate positive impact on her part of the project.
• proposed a plan that the client should execute (not me!) so that she would have some experience of her own to get back to me with when we talked the next time: some new learnings to share.
• avoided talking about the money, spoke about the solution instead! No numbers were mentioned at all at this point. This demonstrated my interest in the project rather than in finding new ways of getting easy money.

The client came back a week later, confirming that the test was successful, and we started the project with a reasonable budget and 50% advance fee! We went on to start with the prototyping phase instead of just a proof-of-concept demo because the client was now confident about having the right technology choice, and the right guy developing it – me!

We didn’t talk about money, but the money just came. Isn’t that something? I solved the immediate problem in my client’s hands who took a good step forward because of my help.

This turned out to be an excellent business relation later on. What was my effort to make it happen? It took about ten minutes of thinking ahead + about ten minutes of calling, and best of all was that those were both activities that I could do while hiking around in beautiful countryside Malaysia!

I admit that I might not be much of a businessman in real, and I have never really even tried to learn any sales techniques, but I guess most clients would say I have a nose for finding practical solutions to all sorts of problems by now, and not only technical. I’m sure you have, too, because you’re a developer- Solving problems is what we do! Let’s take it to another level, the human level, and get to work on making our clients succeed.

Do you believe that my being a successful freelance dev has anything to do with my programming skills?

The sweet spot for freelance software developers

How we devs get our freelance business nicely going is not about the code. I keep repeating this phrase here on purpose so that it gets stuck in your brain forever (hopefully). It’s about finding solutions on which our clients’ businesses depend. Only a part of the problem is of technical nature.

I can easily list the characteristics of the real business case for freelance software developers. Why do you need to be good at handling customers who are not developers themselves? Why do you need to find solutions to all sorts of problems that people, your clients, might have?

The sweet spot (according to my own and others’ experience, if you bother to google a bit deeper) is serving clients who only want app X in their hands: “Can you make it? What is it going to cost?” Why this is the sweet spot for us is because of a couple of reasons:

1. Working with such a client gives you authority over making product-level decisions and design choices that you would otherwise struggle in defining or getting spec’d if left to the client to decide. You can take charge of almost all work yet keep your ears open to the client’s wishes.
2. You are free to set the price of the work to match the value to the customer. This has an important implication on the client’s business, which has to be understood first.
3. You are free to organize the work in a way that you can do the fastest. Hire testers if you need them. Buy graphics if you’re slow at making them yourself. You can quickly see how to optimize your business operation. Nobody is monitoring your work except your own process improvement tools. Clients only care about milestones, which too you can define yourself!
4. Outside the discussion about milestones, the client never bothers you with detailed questions or any kind of micro-management. The client is probably too busy running his/her own business!
5. In the long-term, you may be seen more as a business partner than just some developer who can be swapped at any time for a cheaper one. This is because you were a critical part of making the first project a success in the first place. You took care of it; it was your achievement. Why would the client even ask anyone else?

Although I’m a bit of an efficiency freak with a high tendency of favoring Point 3 here, I’d say the last point is the most important one. I’d argue that working for end-user-level customers is far more profitable than doing code monkey work for other devs who know precisely what your work is worth and might ask you to revise your code just to match their own coding style.

Being good and fast is not only preferred by the client but is also the only right way to develop software and sell it with profit when you’re a freelancer. In case you haven’t realized yet, that’s what we do. Our business is selling software to our customers. The software is part of the overall solution we give to our clients, and coding is just one part of the business operation.

It is possible to learn how to like and enjoy working with non-technical clients in many ways. Nowadays I can honestly say I’m addicted to getting calls from all kinds of different people from all around the world and very curious about what they want to achieve in the long term and how I can get the starting phase to go smoothly.

Spec’ing, discussing design choices, revising requirements, and testing early versions of the app can actually be a lot more fun when not done with another developer! The different perspective makes a big difference and if you decide to think of it in a positive way it won’t take long to start liking it.

Let’s be clear. Selling complete software to customers is the high-end business in freelancing. Selling pieces of code to other devs is a low-end business. And the prices correlate, I guarantee it. Point 2 explains why.

Glassdoor says an average developer earns about US$80K a year, the hourly rate being about $40 (simplified calculation here includes 12 months, 21 workdays in a month, 8 hours a day… I leave out holidays, performance bonuses, taxes, personal overhead costs, etc. here).

I see many good devs earning double and most of the very specialized ones triple or even more compared to the corporate code monkeys. This leaves very nice options for the freelancer. Let’s say you earn $100, 2.5 times the average. You can choose to:

• Work full-time and earn that 2½-time income compared to Average Joe the JavaScript Dev.
• Work only 67 hours a month to earn the same as Average Joe the JavaScript Dev and spend your remaining 101h on
  • learning new things (highly recommended!)
  • optimizing your approach of finding clients (an ongoing process of any top freelancer)
  • maintaining client relations
  • developing new business ideas that allow you to create passive income
  • developing your brand and promoting your online visibility
  • enjoy life (also highly recommended!)
  • … etc.

You will have so many options that the sheer amount of choices could feel overwhelming at some point. I went through this kind of phase in 2017, as I remember. You could do anything!

I would also argue that creating good, long-term client relationships would be the best case for efficiency too. Working with a couple of clients at one point in time is optimal. Not too many at the same time. After all, it doesn’t take much calculation to decide which business operation would have a smaller overhead in pitching, discussing, and starting a project:

1. A thousand hours for one customer
2. One hour for a thousand customers

The only advantage in Option 2 is getting paid frequently, which in turn would lead to more work done on the accounting side. 😉 Really, it’s a no-brainer. Aim for the high-end business, selling software to real business people. Be a complete solutions provider, not just a poor dev.

Customer relation is a delicate thing; it’s a form of art. Fortunately, it can be learned!

But it is about the code!

There are, however, some limitations that might prohibit this lucrative business from being something with which you can start, and it relates exactly to your command of overall software development. Hitting this sweet spot comes with the responsibility of delivering everything the client needs. A certain level of maturity is required before getting into the high-end market. This is why the high-end market could be the bitter-end spot for you:

• You might not be able to understand all the business requirements the client has, which may lead to putting an enormous amount of work on secondary features, which results in much redoing which can make you run the project on the deficit side.
• You might not be able to read between the lines of a particular type of business proposition. What’s the real deal here, not now but later?
• You might appear slightly unprofessional by accident, which can result in a discussion on your rates unfavorable to your business.
• You might not have experience of delivering entire products, only features and modules so far. (This would be one of the biggest risks if you haven’t launched a real product before!)
• You might lack design skills (or skills for getting design work organized) which makes your end product look … interesting (that’s how a nice customer would say it perhaps).
• You would not have anyone else to coordinate the work for you. It’s just you figuring things out. You write all the code you ship. It’d better work!

The overall handling of a software development project is critical. Without a high-level grasp on these things, there isn’t anything else we can expect but a disaster. Attempting to work in the high-end business with only the low-end experience and a pure developer’s mindset can turn into a nightmare where neither party is happy.

The worst-case scenario that could happen is that you would get a project without knowing how to deliver all of it. Partial success rarely counts as success, at least in the client’s mind, especially if they need to pay in full! There could even be a legal mess to clean up later. Proceed with care.

I have to note that we do need to keep the technical standards high, of course. There’s no escape. But that’s assumed when you start freelancing. Check out Why and How New Freelancers Keep Failing, Part 1: The Developers as a fair warning. Still, I highlight that the tech part is the easy part for us.

The famous last words on how to freelance as software developer 🙂

It took quite a few words to get this far, but I hope this article helped you to get the right impression about freelancing as a software developer. I urge you to avoid being/becoming/remaining a mere code monkey and challenge you to rise through the ranks to only work in the sweet spot. It’s sweet enough, believe me. 🙂

The part where we software guys can improve most is the customer handling and business side of freelancing. Luckily, these skills can be learned, for example. As long as you’re consciously focusing on it, you can learn it on your own in practice. Even better you can include some guidance from an experienced freelancer in your work process. Feel free to reach me in case you feel a bit shaky.

Remember, when starting up your freelancing as a software developer, you don’t need to code. You need to focus on everything else.