Trials and Upgrades Won’t Save Independent Software Developers

Every six months or so a new round of discussions about how Apple is killing independent developers arises. Many argue that Apple has hurt independent developers by not allowing upgrade pricing and free trials. The belief is that this would help indie devs make a living because free trials raise prices and upgrades allow for an on-going revenue stream, one that pays for developers to continue improving their software.

Lately, this has become the latest thinking for why the iPad is not doing well. The thinking goes that there is little incentive for independent developers to write world-changing applications for iPad because there is just no money to be made, and without those world-changing applications the iPad languishes with few reasons to purchase. After all it is neither an iPhone nor a laptop, sitting somewhere in between without a truly compelling reason to purchase a new one every year. After all, I can consume content (news, movies, tv shows, etc.) on a three-year-old iPad almost as well as I can a current one.

I’ve long argued that, while Infinity Softworks has as good a reason to support trials and upgrades as anyone, it won’t make a difference to the independent developer today. It’s too little, too late. If there had been trials and upgrades in 2008 or 2009 maybe it would have made a difference (I’m still skeptical), but not today. It’s a matter of expectation and the realities of numbers.


Customers are trained just like anyone else and the baseline becomes the expectation. Here in the United States we expect lights to go on whenever we turn on a lamp. When the electricity goes out it makes major news. Remember the blackouts in California just a few years ago? Yeah, that was huge news. People were frustrated and lots of ink was spilled (can we say that anymore?) talking about how this will be the future, rolling blackouts and other electrical grid problems caused by climate change and an increasing population.

Our expectation here in the States is that the electricity is available whenever we need it. That is not the case in other countries. We worked with a company in India a few years ago. It was often we had to postpone a meeting or adjust our schedule to accommodate their electrical situation. While it left us wondering, none of the developers in India blinked. Their expectation was that electricity was intermittent. Use it while you’ve got it, save and backup often.

Already in 2008, when the iPhone launched, the landscape for software was changing. More and more companies were becoming successful with web services, which necessitated subscriptions and advertising. There were fewer and fewer success stories of packaged goods, one-time priced products. Apple walked into the middle of this with the iPhone and shortly thereafter so did Google.

The expectation die was already cast, however. When the iPhone launched, apps were priced with a virtual ceiling of $10. That was the price of the first game and many of the first applications. A few years later Apple launched their Office-suite of apps (Pages, Numbers, Keynote) at $10 per app and then free. In customer’s minds, a very polished, professional application from a well-known developer for an iPhone or iPad was $10 at most. From anyone else that premium price was $5. Sure there were a few niches where the developer could still get more but those were far and few between. The expectation was that apps were somewhere between free and $5. In 2009 we experimented, raising the price of our top 5 finance app from $5 to $10. Our sales completely disappeared.

That expectation, for iOS and Android, has lived on now for eight years, cementing itself in the mind’s of app buyers. It is unlikely that would change with trials and upgrade pricing, especially when most categories readily have at least a half dozen alternative applications to choose from.

The Role of Scarcity

In 1998 we launched our first application for PalmPilot, a financial calculator called FCPlus (later renamed to powerOne Finance). We charged $39.99 for the application in those days, a high but not outlandish price for a handheld software title in the late ’90s. Average prices for Palm software was $10-20 per title. We priced at $39.99 because our only competitor, Landware’s Financial Consultant, was the same price.

Read that again: our ONLY competitor. There were not ten alternatives. The expectation was that a good software financial calculator for Palm OS would run a buyer $40 (or more). But even $40 was cheap by desktop software standards. Other products in the Windows calculation space were hundreds of dollars and even hardware calculators cost more.

We can’t say the same today. There are no less than 20 alternative financial calculators in the iOS App Store. While demand expectation of low prices remain, the plethora of undifferentiated competition puts pricing pressure on the supply side of this equation as well. And let’s face it: it is nearly impossible to differentiate when you have only a few screenshots, a description (that no one reads) and a few reviews to go on.

Software’s Changing Face

In the late 90s/early 2000s I had a theory that the price of software for mobile would remain at about 10% of the price of desktop software titles. After all the price of mobile hardware was about 1/10th the price of desktop computers and the screen real estate was about 10% of a typical monitor. Again, expectations, this one dictated by its relativism to other computing systems.

A typical Windows application was somewhere between $100 and $400. A typical Palm or Pocket PC title was $10-$40, right about 10%. The price of a desktop computer was $2000-$4000 while the price of a PalmPilot, by 2001 or so, was $100-$400, or roughly 10%.

Soon thereafter, though, laptop and desktop prices fell. Now a high-end, high-quality laptop can be had for $1500 with Windows laptops as low as $500. And software prices have fallen alongside. Apple used to charge $100 for its desktop Office suite, which became $20 per title then free. A $400 Microsoft Office suite became $80.

It isn’t stopping there, though. In 1998 when I wanted to understand the software business I looked to Microsoft, Adobe and Intuit. Each sold their software one-time with upgrades. Now, not so much. All three are moving to subscriptions and Intuit just announced it is trying to sell all their products that don’t have subscription pricing.

The Financial Reality

My problem is not that it hurts to try trials and upgrades, my problem is that there is too much hope in a solution that won’t pay off. The reality is that smartphone and tablet software pricing is so low that even trials won’t help us. If a premium application is $5 today, what do trials buy us? If we can raise the price at all (too many substitutes as discussed above), can we raise the price to $10? How about $20? A typical paid app in the store will generate a few thousand downloads over the course of a year. In the financial category, 10 units per day is able to keep you in the top 50 paid apps in the category, which is not an easy task to accomplish these days. That’s the equivalent of 3650 units per year. We’ll use 5000, a 33% premium, instead to make the math easier:

  • 5000 units × $5 – 30% = $17,500
  • 5000 units  × $10 – 30% = $35,000
  • 5000 units  × $20 – 30% = $70,000

Even the $20 price is definitely not enough to support even a single developer in most of this country. But what about adding upgrades? From my days selling one-time with upgrade products on platforms that supported it, I know that roughly 10% of the customer base would upgrade to the next release:

  • 5000 units  × 10%  × $5 – 30% = $1,750
  • 5000 units  × 10%  × $10 – 30% = $3,500
  • 5000 units  × 10%  × $20 – 30% = $7,000

So year 1 is $70,000 gross, year 2 is $77,000 gross. And that’s gross revenue! None of the expenses of running a business are taken out yet. While these might be great hobbyist revenues, they still don’t mean enough money to inspire a team of people to write incredible software that changes how people use iPads.

To make a full-time, independent software business work in the United States, I estimate (based on experience) that we need to generate roughly $150,000 per year per employee before expenses. Adding trials and upgrades, frankly, aren’t going to get us there.

Duck and Weave

I surmise that the business of being an independent developer is much like the job of an NFL running back. The backs job is to find the holes left by the 400 pound lineman and charge through them.

As mentioned in 1998 we launched our first Palm title: FCPlus financial calculator. A year later Palm came to us and basically told us to give them a financial calculator free or they’d go get one from our only competitor. Microsoft at that same time had launched PocketPC and included a financial calculator. Palm needed one, too¹.

We really had no choice. Relying on the fact that Palm just wanted to check a box that said “includes free financial calculator” we created a Lite version of FCPlus, gave it to Palm to bundle and then sold upgrades to the full Pro version for $19.99. (Remember, the full price was $39.99). These bundling deals worked quite well for us, actually, and we eventually developed a product specifically for bundling (powerOne Personal), which was included, at its peak, with nearly 80% of all handhelds sold. The traffic derived from those bundles accounted for 75% of our revenue.

The 400 pound lineman created a hole and we, the 200 pound running back, had to find a way to charge through.

On To The Future

The business of software keeps changing. We need to change with it. As much as we all think it will solve our problems, yearning for a world that has passed us by won’t help. Trials and upgrade pricing are from an era gone-by. They aren’t coming back and, if it did, it wouldn’t have the financial impact we all wish it would.

If we want to thrive, let alone survive, we are going to have to change with the industry. Again, I look to Microsoft, Adobe and Intuit. Their future is clearly subscriptions. Is that our future too?

¹ Yes, the company was that horribly run after Donna, Jeff and Ed left to form Handspring.

Intuit To Sell Quicken

I missed this news two weeks ago but apparently Intuit is selling Quicken, its consumer-grade financial tracking software. In fact Intuit is dumping all of their businesses except their tax filing package, TurboTax, and business-accounting package, Quickbooks. Quicken was Intuit’s original product. It was the centerpiece of their fight with Microsoft. Quicken was a huge deal in its day. I remember reading strategy books about it and Intuit’s rise as a company.

If it wasn’t clear before, traditional software sales are dead, and Intuit dumping Quicken is the final nail in that coffin. Microsoft has moved Office to subscription, so has Adobe with its Creative Suite. Intuit is focused on Quickbooks and TurboTax, both products that are perfect for subscriptions. These were the Big Three software companies when I first got in the business 18 years ago and every one of these products were sold for a one-time price at the local store. Now, none of them can be bought this way.

18 years ago I followed Intuit’s (and Microsoft’s) lead, developing reasonably priced software, selling it for a one-time + upgrades price. I think it’s high time I follow their lead again.

Water, food and smartphone

There is water, food and smartphone. Those are the only three things that have (or soon will have) 1:1 penetration for the world’s population. It makes stuff like tablets and watches look like piddly little businesses, even though those are huge businesses by any other standard. Apple alone sells millions of units which generate billions in revenue every quarter.

There will likely never be another smartphone. Its reach and scale are impossible to replicate. But it doesn’t mean there isn’t 20-50 multi-billion dollar “niches” out there that companies like Apple, Samsung, and Xiaomi can profit from, and the combination of those “smartphone ancillary” products combined might be as much revenue as the smartphone by itself.

Keeping Portland Weird

I was downtown for one meeting (NW24th and Quimby) and had another at NW14th and Everett so I decided to walk.
While walking up the street on 23rd is coming at me a completely naked man with a hand-written sign around his neck. I thought maybe the sign would indicate why he’s walking around naked, some political statement, something, but the sign was in pencil and I couldn’t read it from a distance. And of course I don’t want to stare at this naked guy trying to read this sign. So I keep glancing and can finally read it as he comes by: “I lost my pet.”
Ah, Portland.

Web! Native! Both?

I once had a professor who insisted that writing software was 70% planning and 30% implementation. I thought he was crazy at the time. 18 years later I completely understand where he was coming from.

Nolan Lawson kicked off another round of discussions about using web technologies exclusively to build native apps (and a follow-up here). The native app people always come down on the side of no way. They rightly point to the fact that web apps don’t feel like native apps. The animations between views aren’t as smooth, the look-and-feel can never be native enough, and the “write-once, run-everywhere” approach just means really mediocre applications everywhere. Learn to write native code!

The web-centric developers point to the complexities of learning web, iOS, Android, Windows and Mac program. Learning any one language well is hard enough. Learning five well enough to write performant apps and maintain those apps is nearly impossible. Besides it is the web that made Mac relevant. We already have write-once, run-everywhere. It’s called a web browser. Why should we go back to coding like its 1995?

These arguments, however, ignore a third way: the hybrid app. The hybrid app is where some of the application uses web technology and some use native code. We use embedded web views wrapped within native code to present the application to the customer.

Apple already does this in some of their apps today. The Mail app uses web views to show email. It is also rumored that iMessage uses web views to show individual message bubbles. iBooks may use web views as well. Third-party apps, especially reader applications, RSS apps and apps like Flipboard and read-it-later applications use web views in this way as well. The entire app isn’t HTML and the entire app isn’t native.

The key to this approach is understanding clearly what makes each of the various technologies superior and then use each of those technologies appropriately to build a superior experience. Just like in the days when developers would use Assembly to write really CPU-intensive aspects of their apps, web technologies can be used to do what they are best at: rendering and formatting text, especially when combined with other medias. Have you ever tried showing an image along with a block of formatted text in iOS or Android? How about a bulleted list with text around it? It’s possible but it isn’t easy. HTML makes that simple, even giving us the ability to edit that text and return the output to the native app.

HTML fails miserably at animation¹, though, and it is nearly impossible to make HTML look like Android or iOS. Don’t use it for that. Learning the basics of navigation, list management and animation techniques in any native platform, though, takes a much smaller amount of time and doesn’t require nearly the skill set.

This is why planning is so important. When we started working on Equals we broke the product down into small pieces, deciding how to accomplish each piece, thinking ahead to both how the app would work on the web and also how it would be presented on native platforms.

We used Equals’ technology to develop our first mobile app: DEWALT Mobile Pro for Android. I had never written an Android app before this. (powerOne for Android was developed by a third-party.) True to my word, DEWALT Mobile Pro is a hybrid app: it uses all native Android code to present the list, calculator and various dialogs, and uses HTML technology to present the template itself, which combines various elements — images, links, text, and some input keypads — in a single page.

It took less than three months to write the entire application, including learning how to develop for Android. In comparison, it took six months to develop powerOne for iPhone back in 2008. The difference, frankly, was the amount of time I needed to invest in native code that shows and allows data input into the templates.

By utilizing a combination of HTML5 and native code I believe I was able to attain a superior presentation of the templates while, at the same time, maintaining a native look-and-feel for the application. We can shout “native!” “web!” but in the end we should use the technologies — or, more appropriately, the combination of technologies — that make the best applications. Sometimes that’s native code, sometimes it’s web code, and sometimes it’s both.

¹ I am specifically referring to animation that acts like native code. Making a spinner spin isn’t a big deal anywhere. But transitioning from one view to another never reacts well in HTML. If you do any animations, I can highly recommend Greensock’s GSAP technology. It is amazing, and the recommended animation engine by Google for their Material Design stuff.