Why Some Apps Are $2 And Others Are $20: How Developers Price Software

Why Some Apps are $US2 ($3) and Others are $US2 ($3)0: How Developers Price Software

A lot goes into the decision to make one app free and another five dollars, or slap another with a monthly subscription. Most of us don’t see it, but developers wrangle with hard choices when they pick a price tag — choices that might make them rich, just pay their bills, or leave them flat broke.

Illustration by Jim Cooke.

Good software requires a lot of work. While people whine about “greedy developers” that dare charge $0.99 for apps they built themselves, there’s no question that some of the best software costs money, but a ton of great software is free to download. To understand the method to app pricing madness, I spoke with Brian Mueller, developer of the CARROT series of apps, Michael Simmons, developer at Flexibits (best known for Fantastical), and Nikos, from Zabkat (best known for Xplorer2, our favourite file browser for Windows).

Market Trends Define “Reasonable Prices”

Everyone I spoke with had a similar set of questions they ask themselves when choosing a price:

  • What are other, similar apps to mine selling for right now?
  • What does my app do differently than others I compete with?
  • What’s the most common price for apps in this category?
  • What would I pay for this? What value would I return to a customer?

Take what you gather there and you have a pretty good starting point for the price of your app.

Nikos’ describes the process:

Most software “one man shows” like me don’t have a clue about marketing. So you check the competition and see what is “reasonable” for the kind of software you sell. I start selling somewhat lower, but not too much lower, as many people equate cheap to junk…

It’s a simple concept: we associate quality with price. If you see something that’s free or even $0.99, it’s hard to imagine relying on it too much, because it just looks like just another cheap, throwaway app. That might be fine for apps that do one specific thing, or some niche, silly software, but when you’re looking for something important, like a calendar, to-do app, or Explorer replacement, people associate polish and quality with a price tag.

For example, even though CARROT takes a pretty silly approach to productivity, it still gets stuff done for me every single time, which is exactly what I’d expect from an app in the $5 range.

Market Share and Our Expectation of Features Make Even Niche Apps Expensive

Pricing is also about market share. Both Flexibits and Mueller have apps available for Mac and for iOS. In both cases, the Mac apps cost more to buy, and cost more to make. That’s at least partially because the OS X market share is considerably smaller than iOS. In other words, there are a ton of iOS devices out in the world, and not nearly as many Macs. Which means that developers need to price OS X versions higher in order to make a decent return on their development, while iOS apps can be priced lower to make up for that with volume.

There’s another big difference between a desktop app and an mobile app: a user’s expectation of features. Fantastical on iPhone, Fantastical on the iPad, and Fantastical on the Mac might all look similar, but they operate totally differently. The Mac app especially is completely different from its mobile counterparts, operating much more in line with what we’ve come to expect from a “full-featured” Mac calendar. We tend to expect more from our desktop apps and in order to deliver that, developers need to ask for a higher price in return.

In the same vein, few things irritate app buyers more than the lack of universal apps, or one purchase that gets them the same app on all of their devices. Simmons, who has different, non-universal versions of Fantastical for iPhone, iPad and OS X, explains the logic behind this, and why they’re different prices::

The biggest reason we do separate apps is because I truly believe when you design a universal binary app you’re not creating a pure iPad app or a pure iPhone app. In other words, the mission of the design of the app changes. We designed Fantastical specifically for the iPhone. It’s for a mobile device that’s made so you can look at it when you’re on the go. Fantastical for iPad is specifically designed as a portable app that you’ll take more time with, maybe even sitting at your desktop. With the Mac version, it’s a desktop app and we designed it as such. All these different versions allowed us to design these apps with way more functionality and a better experience.

Plus, the iPad market is way smaller than the iPhone market, so sales are going to be lower. The same goes for the desktop app.

It comes down to basic maths here. The more niche a product is, the fewer the unit sales will be, and the higher the price has to be. Beyond that, we tend to expect more functionality out of desktop apps (and arguably from iPad apps as well), and those features don’t just magically appear, they have to get built. That means desktop apps are in the awkward spot of being in a smaller market share, but with the highest expectation of features. All combined, that means desktop software trends higher in price than similar — or even the same — mobile apps.

App Prices Have to Cover APIs and Other Under-the-Hood Services

When an app links to a third-party service, that usually costs money, and that money has to come from somewhere. Instead of building their own, say, live weather or mapping service, most developers use third-party services so they don’t have to reinvent the wheel on their own. Of course, that adds to the cost of the app. Brian Mueller ran into this with CARROT Weather:

[Weather] had costs associated with its weather data API. So I did have to do a bit of maths to figure out how often each user would use the app and figure that into the base price. But it still ended up landing in the same ballpark as the other high-quality weather apps out there.

For example, CARROT Weather uses, which also happens to be the backbone of weather app Dark Sky. Here’s the pricing model for using

You can use the API (application programming interface) in both commercial and non-commercial applications.

  1. The first thousand API calls you make every day are free, period.
  2. Every API call after that costs $US0.0001 each.
  3. Credit us with a “Powered by Forecast” badge that links to wherever you display data from the API.

The “$US0.0001 per API call” might not sound like much, but if your app gets popular (as CARROT Weather did), it adds up pretty quickly. Any time someone’s iPhone’s with CARROT Weather on it dials into that’s counted as an API call. If you have a thousand phones checking in once a day, that’s one thing, but if you have a thousand phones checking in all day, multiple times a day, to keep a weather badge or widget updated, well, that’s a lot of API calls, and a hefty bill. The more an app sells, the more API calls go out, and the higher the cost is to maintain.

This weather API is just one example, but plenty of others are out there. Google Maps, Twilio, and Google Calendar are a few other popular services that have billing schemes based on usage, and most people won’t download a mapping app, calendar app, or messaging app that doesn’t connect to those popular services.

Long Term Support and Updates Aren’t Free

Everyone who makes an app wants it to be successful, but more users means more responsibility to support them. As your app gets popular, users want new features, run into bugs, or just struggle using it. Most developers wind up handling their own support requests, and that turns into a pretty big time sink. Just take a look at CARROT or Flexibits Twitter accounts for a tiny glimpse into just one of those support channels. All that time is money.

This is the biggest aspect of pricing that I never thought of. With free software, our expectations are pretty low. I know it won’t get updated immediately when a new operating system comes out. I don’t have any expectation of support beyond the launch, and expect the app to have quirks. With paid software, I want better than that for my money. I expect it to be compatible with new operating systems quickly after launch. I expect bugs to get squashed in weeks, not months. I expect that if I contact a developer on social media or through email, that I’ll receive a response as soon as possible. I also expect new features regularly, and weird quirks ironed out. Simmons elaborates:

[We ask ourselves] what sort of value are we returning to our customers? Ultimately, we’re making apps for our customers… We absolutely care about what we’re selling. We have a support team, but Kent and I open our support and look at it every day so we know what people are complaining about. Support is definitely a cost, but it’s something we care about because when we look at it we can make our app better.

“Support” means multiple things. It means technical support through email or social media. It means adding in new features that customers are asking for. It means updating an app to work on new version of iOS or Android, and tapping into new features available in those versions. Simply put, it’s a complicated process that doesn’t end after you click the buy button, but it costs developers time and money.

Every single developer I talked with said that when it boils down to it, they want to make enough money so they can make another app. Then another after that. It has nothing to do with the time it takes to make an app (pretty much everyone said their apps would be insanely expensive if they clocked their time). It’s just about doing what they love to do.

Have you subscribed to Lifehacker Australia's email newsletter? You can also follow us on LinkedIn, Facebook, Twitter and YouTube.

Trending Stories Right Now