Going Independent
I am writing this for anyone who is interested in trying to go independent — either with your own app development business, solo contracting and freelancing, or both.
[…]
For me, the first year was full of learning — how to keep my books, how to deal with taxes, how to continue saving for retirement, how to structure my days, how to manage my time, how to get shit done, how to take time off, and the list goes on. Be prepared for this in your first year and do not give up. My second year was all about making refinements and optimizations to all the things I learned in year one. Finally, in my third year I started to feel like I had everything figured out — I was on autopilot and coasting through all those tasks that were previously bumps in the road. Currently, administrative tasks are a breeze, I have consistent work with long-term clients, and I am able to make time to work on my indie apps.
[…]
Unfortunately, splitting time between client work and indie projects is much easier said than done. You must prioritize what actually earns you money, which is contracting/freelancing. It is very difficult to balance both types of work when you are first getting started. […] What I have found is that it is best to allocate full days to one or the other. Each week I try to do only client work Monday through Thursday, and do indie work on Friday.
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.
[…]
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.
[…]
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. […] 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.
[…]
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.
These are just a few of the numerous pleasant experiences I have had with independent software developers. I cannot say the same is true of big corporate developers — not even close.
[…]
When I buy and use software from an independent developer, it feels like I am establishing a relationship with the person or small team that built it; it feels like we both have a stake in the success of the product. But when I use software made by a massive company, I can feel the power imbalance in the pit of my stomach.
Previously:
- Indie Anniversaries
- Solo iOS Developer Tips
- Indie Apps Catalog
- Slopes 2.0 Business Model Experiment
- What No Indie Developer Wants to Hear About the App Store
- The Indie Game Bubble Is Popping
- The Indie Life
- Who at the Table is an Indie iOS Developer?
- A Critique of the Apple Indie Developer Community
- Marketing Tips for Indie Developers
Update (2023-08-17): Jesse Squires:
What you may not realize is that going indie means starting your own business. Congratulations, you are now a small business owner as far as the IRS is concerned. Don’t worry, that does not mean some sort of formal business entity is necessary (as you will see below). It only means you need to shift your thinking a bit. My goal with this post is to give you a head start on learning how to structure your business, and what to expect regarding taxes. My hope is that you can begin your journey with more information than I had — which was literally zero.
Update (2023-08-28): See also: Accidental Tech Podcast.
2 Comments RSS · Twitter · Mastodon
Nick writes: “Of course, to expect otherwise would only be lying to oneself. The biggest companies in the world do not have the time or staff to handle the feedback from millions — billions — of customers on a personalized basis, so they need to triage.”
But why do we accept that? Apple sells on the order of 10,000 times more phones than I sell copies of Keyboard Maestro. But Apple has 100,000 times more employees than I have, makes more than 100,000 times more profit than I make in revenue, has more than a million times more cash than I have.
So why exactly do we accept that they cannot provide just as good a service as an indie company? People simply accept that large companies will push the cost of support back on to the customers (with things like crappy chatbots, horrible phones systems that keep you waiting for hours, terrible web forms that force you to try to triage where your query should go in an organisation whose structures you don't understand.
The only reason large companies can't offer as good service as indies is because indies put more emphasis on quality and service and large companies put more emphasis on making more profit.
Apple could to, and they would be rewarded for it in the long run. An emphasis on customer service ends up emphasising fixing bugs and rough edges (because as an indie, who wants to answer the same question over and over, instead you fix the issue). But because large companies push this cost on to the customer, there is little or no incentive to fix all the little bugs and niggles and pain points.
@Peter They can’t provide just as good service because they can’t literally have a Photos engineer—who actually designed and coded a substantial portion of Photos—talk to every customer who has a problem the way you can for your customers. There’s no way to scale that. But could they hire more support people and and testers and do a better job of responding to support issues and of tracking and prioritizing bugs? Yes, that is absolutely a choice.
