Pinprick

Monday, 20 November 2006

Steve Harris wrote an interesting weblog entry regarding the effect of giving away ultra-cheap copies of his app KIT via MacZot:

My aim was to get KIT some exposure. People like KIT when they see it, but don’t know to look for it. KIT got a lot of attention, so that worked and the objective was achieved. Kind of.

For me, what happened afterwards is what was most interesting. Unsurprisingly, I was inundated with support emails, some were bugs, many, many more were feature requests and others were just questions. All were welcome. I did underestimate the impact of this, however. After working my way through them all diligently I found it was the middle of October.

Six weeks vanished and financially, it wasn’t actually worth it, but I see that as an investment for the future. …

Perhaps the most significant thing is that normal sales of KIT didn’t change one iota. What I was selling before the promotion was exactly the same as afterwards. I think I know why.

Reasonably priced bundles are a good way for indie developers to band together. Unreasonably priced bundles — or the outright giveaways that MacZot has promoted — are just a way for hard-working Mac developers to get ripped off. Users might like free and super-cheap prices, and MacZot honcho Brian Ball might like the money from his cut (or even in the case of the outright free giveaways, the attention given to MacZot), but there’s a reason why MacZot has pretty much dried up.

When MacZot debuted earlier this year, their promotions featured big-name apps like SubEthaEdit. These days, well, let’s just say it’s been a long time since MacZot featured an app I’d previously heard of.

The whole “If you give away a few thousand copies you’ll get tens of thousands of full-priced sales later on” idea just doesn’t work.

Here’s the Gruber Theory of Software Pricing, in a nutshell:

Don’t underprice your software in an attempt to appeal to cheapskates.

Let’s say you’re a Mac developer, and you’ve written an app you plan on selling. Let’s assume that your software is pretty good, because if it isn’t good, it’s very doubtful anyone is going to buy it, regardless of the price. (It’s possible to sell a mediocre app, if, say, it does something useful that no other software does, but that’s only going to work until someone else comes along with a good app that does the same thing and steals your users. I’m looking in your direction, Adobe Acrobat.) Let’s further assume that this software is something you hope to make a serious amount of money from, that it’s more than just a hobby.

No matter what this app does, no matter who the target audience is, there are some potential users in that audience who will want to use it but who will not want to pay for it. Most of these cheapskates will not come right out and tell you this (i.e. that they don’t want to pay anything for your software). If you charge $40 per license, they will say, “This is a great app, but it’s too expensive. I’d buy it if it were $25.”

But if you had set the price at $25, they’d tell you it should be $15. If you charged $15, they’d tell you it should be $10. If you charged $10, they’d tell you it should be free. And on that last point, the cheapskates would actually be right. $10 is not enough money to charge for professional quality software. If you, the developer, don’t think it’s worth ten bucks, you really should just release it as freeware. An excellent, popular piece of freeware might help you professionally even if it doesn’t help you monetarily.

The point here is that you can’t set a price low enough to please the cheapskates. If you can’t create software that’s worth at least $20, you’re not going to make it as a full-time indie developer. And if you look at the indie Mac developers who have made it, you’ll see that they typically charge at least $25 for their software.

Of course there are counter-examples. Panic, for example, sells their “li’l apps” for $13, but (a) their two major apps, Transmit and Unison, cost $30 and $25, respectively; and (b) you’re not Panic.¹

In broad terms, there are two major steps for any new commercial app to be successful: breaking out of obscurity, and breaking into the mainstream. The good news is that if your app is well done and the idea is appealing, it won’t languish in obscurity for long. (But the contrapositive is true: if your app is languishing in obscurity, that means it isn’t well done or isn’t appealing, or both.)

There does exist a middle ground between obscurity and the mainstream, where the app is well-known amongst, say, the sort of people who read Daring Fireball, but not known by the vast majority of Mac users who aren’t Mac enthusiasts. Sorry to say, I’m not aware of any magic formula for making that jump.² Some of it is merit-based, but some of it is just luck.

Timing plays a role, too. Brent Simmons’s NetNewsWire is one of the biggest indie Mac software hits in the Mac OS X era. It’s a great app that I use every day, and which I recommend without reservation. But one factor in its success is that it was the first good feedreader for the Mac, sort of like what Eudora was to email.

But the basic formula is this:

Hard Work + Talent = Success

If you look at any long-standing successful indie Mac developer, you can see this formula in play.

A gimmick like MacZot can help lift your app out of obscurity — but you don’t need a gimmick to get out of obscurity. If your app is good enough, it will break out of obscurity on its own, sooner or later, without your having to give away hundreds or thousands of deeply discounted or free licenses. And participating in MacZot won’t help your app break into the mainstream, because normal people don’t follow MacZot.

Pricing any product is difficult; pricing software particularly so, because the cost of goods isn’t a significant factor: it’s all just ones and zeroes. Of course you can set too high a price — but far more budding indie developers fail because their prices are too low than too high. Aim for high quality and set your price accordingly. If you want users to treat your software like it’s valuable, you, the developer, need to market it as though it’s valuable.