By now you are probably wondering how much more this Jury guy can go on about elasticities and pricing and all the rest of these shenanigans. Well, this post will wrap things up on this topic. I've have spent the past four posts extolling the virtues of demand curves, revenue maximization, charging what your software is worth, and avoiding being a commodity. In this post, I'm going to show you how you can take real world data and use it to make better real world decisions about how you price your app.
When we last left our fateful heroes, we had just finished learning about elasticities, demand curves, revenue maximization, and had conducted a very important thought experiment about the price of our app.
The burning question you still find yourself with is this — Can I actually charge a higher price for my app? Well, I'm here to tell you, "It depends." What it depends on, however, should end up shaping not only how you approach product development but also the type of products you choose to invest your time in creating. Let's dig in.
The Top Grossing list is where you want to be. These are the apps that are making the most money, and making money means food on your table and a sustainable business for years to come. Don't be ashamed of making money and don't let anyone else shame you about it either. This is the livelihood for you, your families, and your coworkers.
So what separates Top Grossing and Top Paid apps? Let's take a quick look at some raw data from when I ran these numbers in late February and early March.
At Çingleton and NSConference this year I spoke at length about App Store pricing and offered an analysis of the trends, problems, concerns, and recommendations for how to navigate these waters as a developer. At the urging of Craig Hockenberry, I decided to turn these into a series of blog posts so there's a good written record and searchable form of this advice. I hope you enjoy the read.
Deploymate is a simple concept, executed wonderfully by developer Ivan Vasic. Deploymate quickly and easily tells you if you are using an API in your iOS or OS X project that isn't present on the minimum OS your app is configured to support. As any experienced Cocoa and Cocoa Touch developer can tell you, missing these small availability details is incredibly easy. It's also incredibly painful when you do.
Last week brought a couple high profile announcements in the tech world. Google announced it would shutter Google Reader on July 1 and Dropbox announced it had acquired the hugely-popular-but-how're-they-gonna-make-money Mailbox app. At face value, these were two separate and unconnected events but they bear a lesson for all of us to take to heart: Running a sustainable business requires generating sustainable revenue. Charge money for what you create.
If you've used a computer in the past 30 years, you probably had the same reaction I did — extreme sympathy and a sinking feeling in your gut as you recalled the times you've lost precious data to a computer. Maybe it was a college paper, that email you were almost finished writing, or pictures of your kids. We've all been there before.
Today I am pleased to announce that I will be joining Black Pixel later this month in a new director-level position and as a partner. Black Pixel is one of the foremost iOS and OS X app consulting firms in the industry, and I am excited for the opportunity to help lead their development and consulting efforts alongside a skilled management team.
For several weeks now, Johanna has been asking me what I was going to name my new BMW. Her black Ford Focus is already a named member of our household, going by the ever appropriate “Schwarz” (black in German).
I’ve never named a car, so this was an odd task. How do I name a car I haven’t met? What should I be considering when naming it, anyway? Is it male or female? And how the hell do I pick a good name? Ugh, this was going to be complicated.