Why Some Apps Cost $ 2 and Others $ 20: How Do Developers Rate Software
It takes a lot of deciding to make one app free and the other $ 5 or give another a monthly subscription. Most of us don’t notice this, but developers struggle with difficult choices when choosing a price – choices that can make them rich by simply paying their bills or leaving them hopeless.
Good software takes a lot of work. While people are complaining about “greedy developers” who dare charge $ 0.99 for apps they create themselves, there is no doubt that some of the best programs cost money, but tons of great software are free to download. To understand the insane app pricing method, I spoke with Brian Mueller , developer of the CARROT series of apps , Michael Simmons , developer of Flexibits (best known for Fantastical ), and Nikos of Zabkat (best known for Xplorer2 , our favorite file browser for Windows ).
Market trends determine “reasonable prices”
Everyone I spoke to had similar questions that they asked themselves when choosing a price:
- What other apps like mine are on sale right now?
- How is my app different from other apps I compete with?
- What’s the most common price for apps in this category?
- What would I pay for this? What value will I return to the buyer?
Take what you put together there and you have a good starting point for the price of your app.
Nikos describes the process:
Most of the programs that “one person shows”, like me, have no clue of marketing. So you check the competition and see what is “reasonable” for the type of software you sell. I’m starting to sell a little lower, but not much lower, as many people equate cheap with junk …
It’s a simple concept: quality is associated with price. If you see something free or even $ 0.99, it’s hard to imagine that you rely too much on it because it just looks like another cheap one-off app. This might be fine for apps that do one thing, or for some niche, stupid software, but when you’re looking for something important like a calendar, to-do app, or an Explorer replacement, people associate brilliance with quality. with a price. tag.
For example, even though CARROT takes a rather silly approach to productivity, it still does the job for me every time, which is exactly what I would expect from a $ 3 app.
Market share and our expectations for features make even niche apps expensive
Pricing is also related to market share. Both Flexibits and Mueller have apps available for Mac and iOS. In both cases, Mac apps are more expensive and more expensive to manufacture. At least in part, because OS X’s market share is significantly less than iOS. In other words, there are tons of iOS devices in the world, and not many Macs. This means that developers need to charge higher prices for OS X versions to make a decent profit from their development, while iOS apps may have a lower price tag to compensate for this in volume.
There is another big difference between a desktop app and a mobile app: the user’s expectations for features. Fantastical on iPhone, Fantastical on iPad, and Fantastical on Mac may look the same, but they work very differently. In particular, the Mac app is completely different from its mobile counterparts, working much more than we would expect from a “full-featured” Mac calendar. We tend to expect more from our desktop applications, and in order to do this, developers need to charge a higher price in return.
Likewise, there is little that annoys app buyers more than the lack of universal apps or one purchase that gives them the same app across all their devices. Simmons, who has different, non-generic versions of Fantastical for iPhone, iPad, and OS X, explains the logic behind this and explains why they differ in price:
The main reason we split apps is because I truly believe that when you develop a generic binary app, you are not building a pure iPad app or a pure iPhone app. In other words, the mission of the application design is changing. We designed Fantastical specifically for the iPhone. It is a mobile device designed so that you can look at it on the go. Fantastical for iPad is specially designed to be a portable app that you can spend more time with, perhaps even sitting at your desk. In the Mac version, this is a desktop application, and that’s how we designed it. All these different versions allowed us to develop these applications with much more functionality and usability.
In addition, the iPad market is much smaller than the iPhone market, so sales will be lower. It’s the same with the desktop app.
It all comes down to basic math here. The larger the niche product, the less sales per unit of product will be, and the higher the price should be. Beyond that, we tend to expect more functionality from desktop apps (and possibly iPad apps as well), and these features don’t just magically appear, they need to be created. This means that desktop apps are in an awkward position with less market share but the highest expectations for features. Taken together, this means that the prices of desktop software are higher than similar or even the same mobile applications.
App prices must include APIs and other hidden services
When an app contacts a third-party service, it usually costs money, and that money has to come from somewhere. Instead of creating their own, say, weather or mapping services, most developers use third-party services so they don’t have to reinvent the wheel on their own. Of course, this increases the cost of the application. Brian Mueller ran into this with CARROT Weather :
[Weather] had costs associated with the Weather Data API. So I had to do a little bit of math to figure out how often each user would use the app and factor that into the base price. But in the end it ended up on the same level as other high-quality weather apps.
For example, CARROT Weather uses Forecast.io , which is also the backbone of our favorite iOS weather app, Dark Sky . Here is a pricing model for using Forecast.io :
You can use the API (Application Programming Interface) in both commercial and non-commercial applications.
- The first thousand API calls you make every day are free, period.
- Each subsequent API call costs $ 0.0001 each.
- Mark us with the “Powered by Forecast” badge, which leads to http://forecast.io/ wherever you display data from the API.
“$ 0.0001 per API call” may not sound like a lot, but if your app gets popular (as CARROT Weather did) it will add up pretty quickly. Every time someone’s iPhone with CARROT Weather calls Forecast.io, it counts as an API call. If you have a thousand phones checking once a day that’s one thing, but if you have a thousand phones checking all day multiple times a day to update a weather icon or widget, well that’s a lot of API calls, and hefty check. The more an application is sold, the more API calls are made and the higher the maintenance cost.
This weather API is just one example, but many others exist. Google Maps , Twilio, and Google Calendar are just a few other popular services that have usage-based billing schemes and most people won’t download a maps app, calendar app, or messaging app that doesn’t connect to these popular services. …
Long term support and updates are not free
Everyone who creates an application wants it to be successful, but the more users, the more responsibility for maintaining them. As your app gets popular, users need new features, run into bugs, or just struggle to use it. Most developers end up handling their own support requests and that can be a pretty big waste of time. Just take a look at theCARROTS or Flexibits Twitter accounts for a tiny glimpse into just one of these support channels. All this time is money.
This is the most important aspect of pricing that I have never thought about. Our expectations for free software are pretty low. I know that it will not be updated immediately after a new operating system is released. I don’t expect post-launch support and expect the app to have its own specifics. With paid software, I want the best for my money. I expect it to be compatible with newer operating systems as soon as it launches. I expect bugs to be fixed in weeks, not months. I expect that if I contact the developer on social media or via email, I will get a response as soon as possible. I also expect new features to be introduced regularly and strange quirks fixed. Simmons elaborates:
[We ask ourselves] what value are we giving back to our customers? We end up making apps for our customers … We absolutely care about what we sell. We have a support group, but Kent and I open up our support team and look at it every day to know what people are complaining about. Support is definitely a fee, but that’s what we care about because by looking at it we can make our app better.
“Support” means several things. This is tech support via email or social media. This means adding new features that customers are asking for. This means updating the app to work with a new version of iOS or Android and taking advantage of the new features available in those versions. In simple terms, it is a complex process that does not end after you click the Buy button, but it costs the developers time and money.
Every developer I’ve talked to said that when it comes down to it, they want to make enough money so they can make another app. Then another one. This has nothing to do with the time it takes to build an app (almost everyone said their apps would be insanely expensive if they were counting down their time). It’s just what they love to do.