Getting started as a freelance software developer can be a bit of an uphill climb at first, but once you’ve established yourself, you’ll find you have much more flexibility over everything from your schedule to your career path. With the right mix of clients and work, you’ll earn solid compensation and focus on projects that interest you.
First, let’s define “freelance.” Technically, a freelance software developer takes on short-term development jobs, typically moving from project to project, client to client, possibly several times throughout a year. This is different from, say, somebody who stays at one job for a year or two, whether on payroll or as a contractor.
The most important thing to remember about a freelance career is that you’re not only a developer, but you’re also a business owner. The clients aren’t just hiring you; they are hiring your business (even though it’s just you). With that, let’s talk about the business side of it.
Marketing
This is the part people probably expect to like the least, to the point that some freelancers hope they can avoid it altogether. Spoiler alert: You can’t avoid it. That being said, marketing your software developer skills isn’t as bad as it might seem!
By “marketing,” we mean getting the word out about your services and connecting with potential clients. There are several ways you can do this, but the two most important are networking (through sites like LinkedIn as well as meeting people personally at conferences and meetups) and using online freelancer websites where clients post their jobs.
Here are the table stakes: Have a strong LinkedIn profile, a great website, and spend time searching for work and emailing people. As a freelance software developer, your portfolio of previous work is one of your key selling points, so make sure it’s as presentable (and comprehensive) as possible.
Focus on “qualified leads.” Don’t send out mass emails to random companies that nobody reads. Instead, spread the word about your services through people you know, such as former coworkers, friends, and so on; and watch the freelancer sites for opportunities. Look for short-term contract/1099 positions. The goal is for you to learn about opportunities, and for clients to learn about you and ultimately connect.
Plan at least four hours per week on marketing… or even as much as a day a week. This is essential to keep your business alive. And don’t wait until the end of your current contract. You want to spend a few hours every single week marketing, even when you’re knee-deep in building an app or service, so that you won’t have a huge gap in time before the next job.
Running the Business and Signing Contracts
Although optional, you will likely want to create an LLC. Doing so is quick and easy, and doesn’t cost much. You file the forms with your state and renew each year. You really don’t need to register an S or C corporation, as that’s quite expensive and a lot more work, especially regarding taxes and documentation.
Get business liability insurance. A lot of freelancers skip this as they don’t think it’s needed. It is. All it takes is one bad client, a lawsuit, and your career is tanked. Why would this happen? Imagine if there’s a bug in your app and it causes one of your client’s own clients to lose money. Who will your client go after? You.
Liability insurance doesn’t cost much; currently prices for freelancers are typically under $45 per month. Search online and look for the bigger names in the insurance industry. You file some forms, set up a monthly auto-pay and you’re good to go. Then hopefully you won’t need to use it.
Next, always sign a contract with your client. We’re not able to give you legal advice here, but software contracts tend to look similar. You can hire a local attorney or find online resources—search specifically for software attorneys who know this business.
And don’t forget taxes. Your clients are not taking taxes out of your checks. At the end of the year, they’ll issue you a 1099 stating how much they paid you. As you receive money, you must set aside a portion of it and make quarterly payments to the IRS and the state (if your state has income tax). This can be tricky because you don’t always know how much you’re going to make in a given year. Most people just take what they’ve made so far that year and estimate accordingly. Trust us, you do not want to wait until the following April only to find out you owe tens of thousands of dollars in taxes—IRS and state penalties and fees are steep.
Also remember that freelancers get charged additional “self employment” taxes by the IRS. The rate is about 15 percent, which is a lot. The key is to take as many legal deductions as you can, thus minimizing your taxable income, which in turn minimizes the taxes owed.
That most likely means hiring an accountant to do your taxes at the end of the year. Online tax-prep apps work well, too, but if you’re new to doing a Schedule C and SE, you might want to hire somebody.
Finally, one important point in a typical software contract: who owns the code after the product is finished. Usually, the client owns it. This makes sense, since you’re building the product for them. What that means is you can’t take the app you built and turn around and sell it again to somebody else without permission from your client.
Managing Your Code
Most developers know how to manage code using sites such as GitHub. But bear in mind that, again, your client likely owns the code; it’s their intellectual property and they won’t want others seeing it, especially their competitors. That means you’ll want private repos, as well as separate repos for each client. You’ll probably even want separate repos for each project, but that’s up to you to decide. In any case, watch the permissions so only the proper people can see the code.
You will also likely want to give your client access to the repo. Sites like GitHub allow you to add people with read-only access. Whether the client will use it depends on whether they have technical people on staff who can even understand it. If anything, it gives them the assurance that they have access to the code at any time.
Listen to the Client… and Build What They Want
If you’re building an app from scratch, you’ll want to follow standard Agile methodologies, and make sure that you and the client agree on the specific set of features up front. Put it in a document, including mockups if possible, and have the client sign the document before you build anything. This is vital so there aren’t disagreements at the end on whether you built what they wanted.
And don’t add additional features even if they seem fun and exciting. This is a common trap because we love to build software! The client isn’t going to want to pay for things they didn’t ask for. Instead, save those ideas for a subsequent version; the client might like them and want to pay for them in a future cycle.
Use a Scrum or KanBan board to track your progress; allow the client access to the board. Keep it updated as you work each day without procrastinating, and prepare for a common problem: Non-technical people have the mistaken impression that, as an app progresses, they’ll see the front end steadily evolving (really, they often think the front end is the entire app and they’ll see it grow like a plant growing from a sapling).
But imagine you spend the first month on the backend, such as the API and the database, and you’re running unit tests and it’s working great and coming together. Then the client asks for a demo to “see what you have so far.” They’re expecting screens, buttons, forms, things they can actually see and click on, but with only some buttons working (since it’s not done yet, of course).
But when they don’t see a front end at all, they’ll get the impression you haven’t actually been working on it. This is a very real problem, and simply showing them your unit tests and code might not suffice. If you get the sense that a client is in the grips of this misunderstanding, then one solution is to toggle your work: do some back end, then some front end, then some back end, so you have something to “show” the client.
Next, be patient with the client. Most likely the client won’t be 100 percent happy with the project. There will be little things they want fixed. How you proceed at that point depends on the details in your contract (which is why you need a contract and why you need to know what’s in it). It’s a similar issue with bug fixes. Are you supposed to fix bugs for free? Again, get the advice of a good software attorney and make sure it’s all in the contract.
Juggling Multiple Clients
You need multiple clients. You don’t want to rely on just one client, who might run into financial issues and pay late, leaving you unable to pay your own bills. But you also don’t want to spread yourself too thin, only able to give a few hours each week to each client. Balance it carefully. Find what works for you, whether it means working on two projects at any given time or one project one timeframe and another the next.
When the work is done, don’t beg the client for more work. (This happens more often than you might realize.) They’re paying you to do a job, and when that job is finished, they might not have more work for you. (Imagine your local car-repair shop calling you every week, asking if you can bring in your car for unnecessary repairs.) While it’s important to occasionally check in with previous clients—send the occasional “hello” email or a holiday card—they’ll reach out with another job if they liked your previous work.
Conclusion
Building a successful freelance business takes time. Landing the first client might not take too long, but that’s when the real work begins, because you have to build a product or write code for them while simultaneously building up your business: tracking expenses, doing taxes, finding new clients, networking. It’s not easy, and you truly are a business owner at this point. But the reward is in the flexibility. Need a month off and have the money to do it? Then go on that dream vacation!
Related Software Developer Jobs Resources:
Software Developer Career Path
