It is hard to make a living in the software industry without crossing the path of a software developer dreaming of becoming independent. Imagine the bliss: no more bosses, no more timesheets, just you and your favorite programming language, day in, day out. Let us be honest: we all dream of building the SaaS or the mobile app of our dreams and living out of its monthly recurring income. Or, in the worst case, at least to have a nice consulting gig that pays for a full year of salary in just six months.
Let us talk about the latter case for a moment, which is, by all standards, the lowest-hanging apple of all freelancing scenarios. To start as a consultant, you need experience, a laptop, a customer, and a cup of coffee.
Such a prospect becomes ever more attractive at a time when the worldwide tech job market went from being at a standstill to actively wiping out tens of thousands of jobs. The situation reminds us of the post-dot-com crash seen twenty years ago.
Plenty of blog posts, videos, and self-help books instruct people on achieving financial freedom by starting a consulting business. The usual narrative is similar in all of them. This article will not be wildly innovative in this respect, but this author can provide some ideas from his own experience.
The starting point mentioned above (experience, laptop, customer, and coffee) is just that: a starting point. In this text, I will give you the required information to become a professional independent software developer. Spoiler alert: your coding skills are necessary, but they are not the most important thing.
Market
Picking your market carefully by specializing to the maximum extent possible should be the first task to accomplish. It is also usually the simplest; to a more significant or lesser degree, we all are specialized in something when working as software developers.
The critical thing to realize is that we can change our specialization later. Many developers, particularly younger ones, might feel trapped by a particular decision. It does not have to be like that; you can migrate to other technologies. You most probably will. Just give it time. If you watch for trends, you will realize your skills will become a commodity in just a few years. It is unavoidable.
Learn economics; sadly, a subject seldom taught in computer science and engineering university degrees. It would be best if you understood how markets work because market laws will define your hourly rate. If your product (your skills and your brain) has more demand than offer (that is, people doing the same as you,) your hourly rate will be higher. It is quite as simple as that.
To make a profit, reverse-engineer the market: pick a vertical with lots of demand and very little offer. Spoiler alert 2: it might not be your favorite technology. Sorry about that.
You can work against the market mechanics in various ways: yes, you can earn a very comfy living even in a market where the rates are on the floor. The first strategy is differentiation; learn how to make people distinguish you from everybody else in the crowd. It takes time and patience, but you can learn the skill. Specialization, conference talks, and becoming an expert in social media are some ways to achieve this. You can also test the market by slightly raising your rates when negotiating with new customers. Doing it will also give you information about your market; keep doing it until the rate of refusals is too big, and boom, you have your market price. And if your rate is not enough to make a living, move to other technical “galaxies” as needed so that you do not have to drop your hourly rate too much.
The big question is the eternal one: how much should you charge? The rule of thumb is that you will spend 20% of your time coding and 80% doing business, so you should rate your time covering your costs and also making a profit at the end of the year. You have to earn per year at least the same as in a paid job in your location; otherwise, you are effectively losing money by being a freelance (Economics 101!) Remember, you will have months without income, and you should use that time to build your business.
And when should your customers pay you? For smaller projects (four to low-five figures in a currency like the US Dollar or the Euro,) there are two payments: 50% upfront and the other half right after the final delivery (invoice to 30 days; 90 days is for big businesses, you have to pay rent.) For medium to large projects (that is, medium-five to six figures,) consider splitting the final invoice in three, asking for one-third at the start, one-third in the middle, and the rest upon delivery. Also, do as Mike Monteiro says: keep all rights to IP (intellectual property) as 100% yours until complete payment. Your customer must not have the right to use your work until you have been fully paid. This clause must be a part of your contract.
Contracts
Speaking about contracts, hire a lawyer and get a standard contract for your business. Such a request is not expensive because many lawyers already have templates ready for this. It would be best if you did this the same day you legally set up your business.
Since you are on a hiring spree, your second hire should be an accountant and ask them about your local regulations. Make sure to keep all tickets and invoices; you might be able to deduct lots of stuff from your yearly tax declaration depending on your location. Not having to deal with taxes will free you a lot of time, so do not make economies in this regard.
Make every customer sign a contract before you do any work. Also, do not sign NDAs. Most customers approaching freelancers instead of more prominent agencies do not have big budgets anyway, and ideas are always less original than they would like to think.
Contracts and plans take me to the following fundamental point: exit clauses. Your contracts should specify how a relationship can become sour and what to do in those cases. A good business lawyer will undoubtedly include such clauses in your draft, but make sure they are there.
One of the typical exit clauses, the simplest of them all, concerns scope changes. Any scope change in the initially agreed project makes the current contract void and demands a new one. It is as simple as that. Your business hangs on a thread because you are selling your brain CPU time by the hour, and most companies prefer fixed-time fixed-cost projects for planning purposes. Scope changes can break your business, which is why “Agile” project management is often the wrong choice for you. A healthy rule of thumb is that the smaller the project, the more “Waterfall-ish” its management should be.
Another common case for an exit clause: do not accept your customer adding third-party (or internal) developers to “help” in the project without your consent, especially after the project has started. Remember Brooks’ law. Collaboration is complicated in small projects; you work on a fixed-time and fixed-budget basis, and you are always one project away from bankruptcy. You cannot afford to lose time dealing with people you do not know.
Firing customers is a healthy activity. If you do not get along with your customer, consider canceling the project and moving on. Refrain from making decisions based on sunken costs: this is another of the things you should learn in business. The money, time, and effort you invested are gone; you should care more about the cash you could lose in searching for a worthless pursuit than what you already lost.
Also, if you can, avoid intermediates (that is, companies hiring you to work on a project for a customer of theirs.) Your margin is thin enough already.
Customers
Keep a CRM database. Resist the urge to build one yourself; you have better things to do. Pay a monthly SaaS subscription and keep track of every email received from a customer, phone call, and opportunity that appears on the horizon.
Customers will come to you more because of your reputation than your open-source code. And your reputation is everything. Always be on time, underpromise and overdeliver. This simple rule will make you stand out from the crowd of the previous paragraphs, and your customers will start talking well raving about you. Others will hire you because of those positive words. No matter how many CRM systems you use, you cannot correctly measure these effects. But they happen, and when they do, it is terrific.
Regarding neurodiversity, becoming a freelance might work slightly better for extroverts: going out, meeting people, and shaking hands is part of the deal. You do not need business cards; you can exchange LinkedIn profiles from your smartphones.
You will have collaboration opportunities with other companies or professionals in your field at some point. To create a complicated software system, write a book, run a marketing campaign, or be a part of a consortium of companies. The golden rule for such collaborations stands in just one word: contract. Draft an agreement, review it, and sign it if you agree. Such arrangements are particularly critical when you deal with friends. The hard truth is that there are no more friends when money is involved.
Management
Forget about “Agile” unless your customer temporarily hires you to work within an established team. If you are the sole contributor for a piece of software, you can (and you must) estimate your work correctly and provide a more “Waterfall-ish” project plan to your customer. Do not expect your customer to have a “standup meeting” every day with you; they are hiring you to solve issues here and now. Get as much information as you need before the project starts, write a detailed project plan, and make the project plan (including its deadlines) a part of the contract, signed and acknowledged by your customer.
Keep track of basic statistics of your past projects: programming language, lines of code, the time required from start to finish, and defect rates. Use those data to estimate future projects. You do not need machine learning models for this, just a basic knowledge of linear regression or COCOMO will suffice, and your estimations will become so good after a while that you will barely believe it.
Remember the insurance trinity: health, accident, and legal. Get the three of them. Many insurance companies provide business packages, adding property damage (very useful if you have an office) and third-party liability.
Invest in suitable hardware: a standing desk, a decent chair, two screens, a laptop with a docking station, a good webcam, a headphone-mic headset, your favorite keyboard-mouse combo, and a fast internet connection. If you enjoy working with music, a nice set of stereo speakers and a subscription to your favorite streaming service will do wonders for your productivity. Use an office with a closing door. Only work 6 hours per day, max. Close the door after that.
Beware of burnouts. Multitasking will become second nature, but you need rest and vacation days. Plan your projects accordingly and give yourself the required time off work. Enjoy what you are doing. Be happy here and now.
Code
Make your work transparent using a simple project management tool with an integrated Git repository, issue tracker, project manager, and a wiki. GitLab, Redmine, Gitea, GitHub, the choice is today wider than ever, and the costs are as lower as a literal zero. Use one that provides CI/CD features to deliver ready-to-install software daily to your customer. Enabling your customers to self-service will make you appear more professional and give you fewer headaches. Make them open tickets instead of sending emails or (God forbid) calling you on the phone. Async is the keyword, and not only for your C# or TypeScript code.
Do not think your code is the only deliverable, as essential as it is. Provide your customers with documentation about and around that code: API documentation, usage samples, build instructions, architecture diagrams, pipeline configurations, unit tests, helm charts, and whatever else is needed to understand, build, deploy, secure, and evolve the product in the future without you being around. Bundle all this information into a “software maintenance manual” and make it part of your final delivery. Consider yourself only a temporary step in a more vast process, and make yourself non-essential. Become transparent. Your customer will thank you for that and, ironically enough, will hire you again because of that attitude.
You should provide a warranty for your work; around 30 days is a healthy time, depending on the scale of the work you provide, but only for correcting bugs. As explained a few paragraphs ago, your work ends when your code runs in production with the requested features. Customers should have 30 days to use the system and report any issues, but they must only be able to request new features with a new ad hoc contract.
Refrain from committing too much time to open-source software. Remember that your focus must be generating cash; we do not need yet another web framework. You are a business now. Giving code away might or might not provide a return on investment, but the statistics show that the chances of this happening are maddeningly small. There is also this urban myth that customers will come to you because of your open-source code. That is simply a myth.
Conclusion
The most important realization of any freelance software developer is the sheer amount of non-coding work involved. You will be surprised, too. Building your own business will give you a different and very healthy perspective on your work and the dynamics of our industry. You will understand why software engineers worldwide must unionize and actively support open-source projects with either code or cash.
Henry Miller once said, “When you can’t create, you can work.” He meant it for writers, but it works for software developers, too; when you cannot create new apps or software or fine-tune your algorithms, you can document, test, clean your desk, and get new customers for your business.
PS: a few more resources to read before you start your own business: The Beginner’s Guide to Freelancing in 2022 by Ali Luke; How To Be A Rockstar Freelancer by Collis and Cyan Ta’eed; The Positioning Manual for Indie Consultants by Philip Morgan; Getting Real by Basecamp; Manage Your Project Portfolio by Johanna Rothman; Blogging to Drive Business by Eric Butow; The Personal MBA by Josh Kaufman; and last but not least Steven Silbiger’s The Ten-Day MBA.
Cover photo by Keenan Beasley on Unsplash.
