Code by Kevin
   


About
Code by Kevin: Programming, code, business, and other pursuits

Your Host
Kevin Walzer, software developer.

Home

Subscribe to RSS Feed
Get a syndicated feed of my weblog.

Archives
2008
2007
2006

Categories
Business
Software
General

        home
Fri, 18 May 2007

One year as an indie Mac developer: What I've learned

In February 2006, I released my first commercial program, a precursor to NameFind. It was a failure, selling exactly one copy, but after taking a few months to regroup, I tried again with a commercial release of PortAuthority. PortAuthority had been under development for two years as an open-source project, had a large user base, and was a better candidate to use as the foundation for building a business. Since then, I've released four more programs, including a significant revamp of NameFind, and have watched my overall sales grow steadily.

I haven't gotten rich from software development. In fact, the income I've earned so far might qualify as a nice supplement to my main income, but isn't yet enough to provide my living. However, by at least one measure--"only the lucky/smart few make >$100 per month"--my software business qualifies as a success, albeit a modest one. In that light, I'd like to share a few insights that have helped the growth of my business.

  • Focus on Mac-only development.

    • Part of the problem with the first iteration of NameFind was that I had released it as a cross-platform application, supporting it on Linux and Windows as well as the Mac. Bad move. It was criticized on a Mac download site as "a primitive Windows port." It worked fine on Linux, but Linux users generally don't pay for software utilities, which are freely abundant through their package manager; there's no way I can compete with "apt-get install foo." And while the program did sell a bit on Windows, I'm not a Windows expert.

    • Deciding to concentrate on Mac-only development isn't a silver bullet, but it has allowed me to bring a sharper focus to what I do. For one thing, it simplifies the amount of coding and testing I have to do; in turn, I can concentrate on optimizing my software to the platform that I know best. Mac users have very high expectations for their software in terms of its user experience, and I can best meet those expectations by focusing more deeply on the Mac.In fact, I began to notice an increase in sales of my software when I ripped out all the non-Mac code in my programs, purchased some Mac-themed icons for my applications, and re-designed their interfaces to better reflect best practices on the Mac.

  • Use technologies that you are most productive in.

    • When I first started programming in 2004, I chose languages that would allow me to get stuff done right away: this specifically meant Apple's AppleScript Studio environment, which allows you to build Cocoa applications in AppleScript. I did a few small projects in AppleScript, which was very useful as a learning experience, but AppleScript itself is a pretty limited language, and couldn't do some of the things I wanted to try.

    • At that point my alternative was to move towards learning Objective-C, Cocoa's native language, or try another higher-level language like AppleScript, but one with more capabilities. At the time, the learning curve for Objective-C looked too steep, so I decided to focus instead on Tcl and Python. These languages provide most of the power of Objective-C--and far more power than AppleScript--yet are easier to learn. As a result, I became productive in them fairly quickly, and have been developing in them ever since. (I discuss my choice of languages in more depth here.)

    • I'm a bit unusual among indie Mac developers in using scripting languages as my tool of choice; most other developers use Cocoa/Objective-C, with some using RealBasic or Java. But my use of scripting languages is, for me, a competitive advantage; I can get busy writing applications, rather than slogging through months of learning the basics. Many developers praise Cocoa/Objective-C as a high-level development framework that lets you build applications faster and more simply than competing environments: perhaps that's true if you're using old-style Mac development, or standard Windows development, as your basis for comparison. But I guarantee you there's no way I'd have five applications released if I were doing them in Cocoa/Objective-C.

    • End users don't care about your choice of technology; they care if your program solves their problem. The religious battles fought between developers over frameworks, programming languages, and so on, mean little to the average end user. What's most important, instead, is paying attention to user expectations in terms of application functionality, look-and-feel, and so on. Careful attention to the Apple HIG is possible in any language and toolkit.

    • My point here is that if you are already productive in Java or RealBasic or another language, you are probably better served by developing your application in your language of choice, rather than going back to ground zero and learning Cocoa. You'll have your application out for sale that much sooner.

  • Find a niche with a problem that needs solving, and deliver a clean, polished application to solve that problem.

    • This point seems obvious, but it's actually the hardest one to achieve. Finding a niche is difficult. There are a lot of applications out there, and a lot of crowded market niches. Does the Mac world really need another RSS reader, another system cache cleaner, another Spotlight enhancer? Doing something useful in any of these categories, that will actually persuade people to part with some cash to purchase your application, is very difficult. If you can find a space for yourself where there is little competition, but some market need, then you will be successful.

    • My own applications are proof of this point. My best-selling application, PortAuthority, has its market niche pretty much to itself right now, and it filled a real need when I first released it. My poorest-selling application, NameFind, competes in a massively crowded niche--Spotlight enhancers/replacements--and it's hard to find a unique place in that niche. My other programs--Phynchronicity, PacketStream and VuMan--fall somewhere in between.

    • You're more likely to be successful if you write a program in response to market need, rather than writing a program to scratch an itch or play with cool technology. "Scratching an itch" can be useful as a starting point, or for learning purposes, but it's not likely to be the basis of a long-term, successful business.

  • Don't be afraid to charge what your product is worth.

    • Again, this may seem obvious, but for me this was a hard thing to grasp. I started out as a freeware/open-source developer; I wrote software for fun, and to learn. It wasn't until I achieved a certain level of proficiency, and had a program in widespread use, that I thought I might be able to earn some income from software development. But I had some questions to answer: Is it right to charge for software? Would users of my formerly free program actually pay for a new version? What price should I charge? I went through all sorts of contortions and changes in direction before finally settling where I am today: charging $20 for my stuff, which seems a fair price given most of the market niches I target, and which provides me with an adequate level of compensation.

  • Don't put all your eggs in one basket.

    • I have five programs currently for sale, with more on the drawing board. Of those five, one (PortAuthority) provides the majority of my income, but all of them contribute something, and some of them have not begun to grow in the way I think they can. The point of having multiple products is to mitigate the risk of any one program heading south. It also means that you can achieve success by having a number of programs that sell modestly. Not every application can be a huge seller--in fact, most applications are not huge sellers.

  • Pay attention to marketing.

    • Don't just put out an application on a website and hope that people download it. You need to put some effort into marketing. Fortunately, the Mac market has a rich marketing ecosystem--an interconnected group of download sites, news sites, and so on, which makes reaching potential users of your software relatively easy and inexpensive. My marketing program consists of posting downloads of my software to VersionTracker, MacUpdate, and Apple; sending news releases to MacNN, MacMinute and PRMac; and sending announcements to mailing lists. This pulls a lot of traffic to my website, and I usually see a huge spike in downloads--and, not too long afterwards, sales. The best part is, it doesn't cost me a dime to do any of this.

These are some of the strategies that have guided my growth as a commercial software developer. Actually building a software business--even the modest one I've developed thus far--is several orders of magnitude more complex than simply writing code. But it's a great pleasure to earn part of my living writing software, and it's an honor every time someone parts with a few dollars because my software has helped to solve their problem.

[/business] permanent link