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.