Welcome to my next post on going indie! In the previous one, I provided a high-level overview and introduction, and answered some of the most common questions I get from folks. In this post I’m going to dive deeper into how you can prepare to go independent, how to find clients, and other tips.
In This Series
This post is part of a series about becoming an indie developer and freelancer.
- Going Independent
- Going Indie: building a foundation, finding clients, and negotiating rates
Disclaimer: As I mentioned before, certain aspects of this series will be US-centric and I acknowledge that folks from underrepresented identities in the tech industry may not be able to replicate my trajectory or have the same experience.
Building a foundation
When I look around the indie dev community within the broader Apple developer community, there is one characteristic that most indie devs share — they do more than just write code. There are too many indie devs that I admire to attempt to list them all here, but they are all involved in more than only writing apps. They write blogs, they speak at conferences, they produce podcasts, they are involved in open source, they publish newsletters.
I recognize that not everyone is able to do open source, or blog, or speak at conferences for various reasons — time constraints, childcare, etc. While these extra activities are certainly not required to do freelance work or make your own apps, they will help tremendously.
There is no single thing you can do to prepare for going indie, and it is definitely a long-term plan you should make. My career trajectory and experience set me up very well to eventually transition to being independent, but I was not necessarily conscious of this in the moment. Much of what I have been able to do originates from a place of privilege. I have had a lot of spare time to dedicate to “extracurricular activities” (open source, blogging, etc.) outside normal working hours when I was working at my full-time jobs in the past.
I got involved in the open source iOS community very early in my career with a number of projects, but JSQMessagesViewController (RIP) in particular was a huge success story. I also started this blog almost a decade ago (!!) and got unexpectedly Fireballed very early — that was pure luck, and it kickstarted my online following. My open source work and blogging helped me get recognized in the industry and build a following on Twitter (also RIP), which eventually lead to me speaking at local meetups, and then at indie conferences.
In many ways, I really lucked out on the timing of my involvement in iOS development — iOS was still somewhat nascent (I started around iOS 5) and there were more opportunities back then for open source to fill-in gaps in the SDKs and improve the APIs. (We did not even have
UICollectionView back then!) There was also a strong iOS meetup scene in San Francisco, with multiple groups meeting regularly, like SLUG (RIP). Many factors contributed to the decline of the iOS meetup scene in SF, but the pandemic expedited that process and left little room for others to try to revive it. After a few years of blogging, open source, meetups, and conferences, I eventually started the Swift Weekly Brief newsletter (RIP) after Swift was announced. The newsletter project led to starting the Swift Unwrapped podcast (RIP) with my friend JP Simard — who I first met through SLUG! And then eventually, somehow, I ended up hosting a panel with Chris Lattner at WWDC 2017. And the rest, as they say, is history.
In addition to everything above, I worked full-time jobs at various companies in the industry for about 7 years. That industry experience was important. One aspect of full-time work that I did not intentionally plan, but that ended up being incredibly valuable was working for a diverse set of companies — they were all different sizes, they were at different stages, they made very different products, and they had very different business models. That breadth of exposure and experience was extremely beneficial when I started working with clients — which were, of course, all very different.
When you put all of these things together, you end up with multiple positive feedback loops. Open source gives you valuable experience in programming and project management, it gives you topics to blog about, and it helps build your portfolio. Those experiences and portfolio pieces help you land competitive jobs. Blogging gives you exposure and recognition, which can help you speak at conferences. Notably, I link to my “Hire Me” page at the bottom of every blog post in case a potential client is reading (you never know!). Speaking at conferences helps promote your open source work, blog, or podcast. Each of these contribute to building your résumé, leading to even better job prospects. Everything provides more experience to learn from and write about on your blog or present at a conference. And, so on. Each of these things has the potential to lead you to a new client, or better yet, have a client discover you. Everything feeds into everything else creating multiple intertwined positive feedback loops, culminating in a body of work and evidence that you can show potential clients to get contracts and freelance gigs. Then, add your indie apps on top of all of this. Your experience helps you write better apps, your apps build your portfolio and provide more content for your blog or conference talks, and so on.
While I do not think everyone needs to follow my exact footsteps in order to successfully go independent or start freelancing, I attribute my success so far to the accumulation of all of these experiences. They all had an incredibly important impact on me, but the most important aspect was all the compounding effects and positive feedback loops. Also recognize that you do not have to do all of these things, especially not all at once. Pick one, maybe two, that interest you the most. Maybe you start a blog first and after you feel established with that, try to speak at a conference.
The last point I want to emphasize is that none of this happened instantly. None of the indie devs you look up to launched a blog with 100 popular posts overnight, nor published a podcast with 100 episodes in a single day. All projects are a gradual process. I did not actively work on all the projects I mentioned above at the same time. Little by little, I slowly built up my portfolio. I spent 7 years doing a mix of working full-time, contributing to open source, blogging, speaking, and podcasting — and notably, not all at once, nor consistently. I had plenty of low points where I did very little outside of my full-time job. I also had periods of time where I focused on a single project outside of work, like the newsletter or the podcast.
Each of these projects is a long-term investment and overtime your body of work grows. Not to mention, your past work often continues to pay dividends in the future. For example, some of my current most-visited blog posts were written years ago! Just like building an app, you have to start somewhere. Furthermore, the majority of the popular projects mentioned above, the ones I am most well-known for, are all now defunct! Not everything needs to last forever, nor should it.
The stronger the foundation you build, the easier it will be to find clients. An important aspect of everything I discussed above is that each of these things is building your network. You meet a lot of people in the industry through conferences, full-time jobs, open source projects, etc. I have met so many people over the years and made a lot of friends. Again, doing all of these extra things outside of a full-time job is not a prerequisite to going indie and contracting, but it gives you a much better place to start — not only because of all of the positive feedback loops, but also because of how it expands your network. And it is important to note that working at multiple different companies when you are full-time expands your network, too. Each time you change jobs to work with new people, your network grows. Furthermore, when your coworkers leave for a new job your secondary network grows.
So far, for the past 3 years, all of my clients have come to me through friends and acquaintances — former coworkers, fellow conference speakers, folks in open source, and other people that I have met during my time in the tech industry. I think this is the best way to find clients rather than reaching out to complete strangers because you begin the conversation with some baseline rapport through your mutual connections. If you do not have the experience I have had with all the “extracurricular activities”, or if you are unable to do so, do not worry. A great first step to finding clients is to reach out to your former coworkers and managers. They may be at a different company now that is looking for contractors, or they might have another connection that is looking for freelancers. However, you would also be surprised how often folks quit a full-time job and return to the same company as contractor, so do not be shy to ask your previous employer about contracting opportunities.
Keeping clients and other tips
This is probably obvious, but the best way to keep clients is to impress them with your skills. Do the best work you can. Build rapport. Work on having clear, pro-active communication with them. Often, one client can lead to another. If a client has a great experience working with you, they are more likely to recommend you to someone else in their network. As you can see, there is a recurring theme of building positive feedback loops.
Another critical task is to ask for feedback. You should do this regularly, during your contracts with your clients. This is for your benefit, to identify your strengths and your weaknesses. Otherwise, you will never know how you can improve. Finally, when a contract ends, ask your client for a testimonial. They may decline, and that’s ok, but it never hurts to ask. Be sure to ask permission to publish the testimonial. Testimonials are so valuable to your continued success. They provide a source of legitimacy for new clients and can help address hesitations they may have when deciding whether or not to work with you. You can find the testimonials I have collected here. Also note that some of my testimonials are from when I worked full-time jobs. If you need to jump-start your collection, ask one of your former managers for a testimonial.
The final piece of advice I have regarding clients is to avoid the predatory freelance platforms that are attempting to gig-ify contract and freelance work. These are platforms like Upwork, Freelancer.com, Fiverr, etc. They all facilitate and foster a race-to-the-bottom for hourly rates, impose excessive fees (up to 20% of your hourly rate!), and are generally nothing more than extractive middlemen. Think Uber, but for freelancers. You are their product. These platforms exist solely to further commodify your labor (beyond capitalism’s existing commodification of labor), de-value your highly-trained skills, and disguise wage theft through the collection of predatory fees. If your only option is using one of these platforms, you are better off working a full-time job.
Negotiating hourly rates or project rates is difficult to discuss generally. There are so many variables to consider with any given client and project, as well as your skill level. I cannot comment on other areas of expertise in the tech industry, but based on my experience with freelance iOS development, hourly rates range from $100/hour to $300/hour. Most commonly, what I see is $150-200/hour. If you are just starting out, it may be worth your time and energy to take some lower paying contracts to build on your experience and collect testimonials. But our goal, obviously, is to get the highest hourly rate possible.
You should determine your limits and requirements before negotiating with clients. You must ask yourself, “am I willing to lose this potential client over hourly rates?” If you do not want to work for less than $150/hour and a potential client is unwilling (or unable) to meet this requirement, then you need to be comfortable and confident enough to not only walk away, but also not regret passing on that project. Will you later think to yourself, “damn, I really should have taken that project for $125/hour”? If so, then you did not accurately determine your limit. It does not matter what your limit is, and everyone’s will be different. What matters is knowing your limit and sticking to it, otherwise you will be miserable working for too little, or regretting a missed opportunity. It is also worth considering what types of projects you will not work on. For example, I do not fuck with cryptocurrency and NFTs. If a potential client project deals with those things, I am not interested.
One important thing to remember is that all parts of a contract can be negotiable. For example, suppose a client offers $125/hour at 30 hours per week, but you have recently been working contracts for $175/hour. You could instead offer $175/hour at only 20 hours per week, which is still within their weekly budget. And you can propose that you try this for one month and then re-evaluate. I have been in a similar situation that ended up working out very well — the client was pleasantly surprised and more than pleased with what I could accomplish with only 20 hours each week. Many clients think they need someone full-time, but they rarely do. As a contractor, you are removed from much of the company bureaucracy, which gives you more time to do actual work.
Another strategy is to negotiate working at a lower rate for a specific duration, at which point you and the client decide if you both want to continue. If so, you both agree to increase your rate. For example, you can propose working for one month at $125/hour. At the end of that month, you and the client re-evaluate — are you both happy with the progress so far and do you want to continue working together? If yes, then your rate goes up to $175/hour. You could also take this approach without adjusting your rates, and work for the first month at your full rate. This strategy gives both you and the client an opportunity to evaluate the pros and cons, then commit or walk away. Most often, clients are hesitant to pay higher rates because they do not understand what they are getting. Offering these introductory, “probationary” periods is a low-barrier way to show them what you can do.
Philosophically, I have issues with hourly rates as they do not capture the true value of your labor. If you are highly skilled and great at what you do, then you can complete tasks efficiently and quickly. But getting work done quickly at an hourly rate punishes you for being extremely good at what you do. If a task takes you 1 hour at $200/hour, that’s $200. But if it takes you 5 hours, that’s $1,000. The logic does not make sense. If you can complete a project in one month versus someone else that will take 4 months — aren’t you more valuable than the other person? Yes, and so you should be paid more. This should factor into how you determine your hourly rates. The better you are, the more you should charge. This line of reasoning is how you convince your client to pay more — clients do not place more value on a project taking longer.
Anyway, I could write an entirely separate post on hourly rates and the value of labor. Unfortunately, hourly rates are the norm and project-based rates are not very common. This is what we’ve got to work with for now, which is why your rates should be higher rather than lower. I have never worked a contract for a project-based rate (yet). In the meantime, if this topic is interesting to you, you should watch this brief video from Chris Do that clearly articulates this conundrum. His other videos are great, too!
Today we covered how to prepare yourself for going independent, creating positive feedback loops, the importance of networking, finding clients, and negotiating contracts. I hope this post was helpful if you are considering going independent. There is still more to come in this series. In future posts I will discuss bookkeeping, taxes, saving for retirement, and more! Stay tuned.