A Comprehensive Guide to App Pricing Strategies and Tools
Tips and tricks I've learned from building my app business
Figuring out how to price an app is one of the most difficult challenges of building a successful app business. Pricing is also a topic that is infinitely deep; any one of the topics I cover in this post could easily become its own 200-page book. So rather than teaching you how to price an app, I’ll show you how I think about it in practice and will reveal the biggest lessons I’ve learned.
Prerequisites for Pricing an App
Although none of these are necessarily required, putting these ideas into practice will help you make more informed pricing decisions. In fact, you’ll have trouble finding a successful pricing strategy without them. There are exceptions, of course, and the one-size fits all same approach won’t work for everyone. But I recommend checking off these boxes and following the steps.
Have a Regular Flow of New Users
If your app has zero users, the pricing structure you choose doesn’t matter. In that regard, you’ll want at least 50+ app installs a day, while retaining at least some of the users for a few weeks and/or months. This is evidence that your app is providing utility to users, which means there is an opportunity to generate revenue. It also gives you a big enough sample size to start surveying your users.
Chutzpah: “Extreme Self-Confidence or Audacity”
Do not be afraid to charge money. I think all first-time developers start out feeling a little shy about selling their product, but don’t gate-keep yourself from making money. Let the market decide if your prices are fair.
Once you start making money, you’ll get your occasional bad review or angry user email—we’ve all been there. But trust me, you’ll develop a thick skin and stop feeling bad when these things happen.
The fact is, publishing an app on the App Store requires intelligence and hard work. You spent your own valuable time engineering a product designed to improve people’s lives in some way. So it is okay to ask your users to pay for your product. It is even okay to ask your users to pay lots of money for it. There’s nothing wrong with making a $1,000/year product if it provides some users with $1,000 worth of value.
I’m emphasizing this point because I know there are innumerable indy developers out there leaving money on the table. Our favorite company, Apple, isn’t afraid to ask customers to pay a premium price for its products, and you shouldn’t be either. Never assume that you know how the market will react to certain pricing. Try things, gauge the reaction, and adjust accordingly.
Pricing Model
Right now it seems like everybody is offering a subscription app, and for good reason. Subscriptions are one of the best ways to make a dependable, stable living off the App Store. However, it’s important to first consider which model makes sense for your app. I’ve tried to fit all my apps into the subscription category, but the truth is, whether that’s feasible or not really depends.
Here are some questions I ask myself when deciding on a pricing model:
Who is using my product? How old are they? What gender do they identify with? What countries are they from? What languages do they speak? These are important criteria to know when determining how much money users have and how willing they are to spend their money on an app.
There are some pretty intuitive learnings here that I’ve validated with my own data. For example, older users and/or those from richer countries with more disposable income are more likely to spend money, whereas kids are less likely to spend money.Why are they using my product? Is it for entertainment? Does it help them run their businesses better? Does it help them improve their health? Do they see this product as an investment?
I’ve learned that two of my apps (Hashtag Expert and Command) attract business users who are using the products to grow their own businesses. They see my apps as a justifiable expense where there will be ROI; thus, for them a subscription makes sense.
My other app (Caption Expert) appeals to kids and young adults. They use my product for fun and because they’re younger, they don’t have a lot of disposable income. With this particular app, I’ve had little to no success with subscriptions despite trying everything to make them work, so I’m exploring ads and other creative solutions.
I’ll dive deeper into all this at some other point, but the important takeaway here is: Think strategically about what pricing model makes sense for your app and your users because the same method won’t work for everyone.
Your Tool Kit for Figuring Out Pricing
Pricing must be viewed as an iterative process. It is never “finished,” and you need to constantly revisit your approach. The iterative process means you determine a hypothesis, test it, analyze the results, and repeat. You keep doing this over and over for … well, forever.
There are lots of different vectors to be testing on: when you show the paywall, what terms your subscription offers, what features are part of the premium tier, whether there is a free tier, and others. Before discussing those variables, here are what I consider the most important tools to have in your app pricing toolbox.
Event-Based Analytics
This one is often overlooked, and it’s essential for pricing. You need a tool like Mixpanel or Amplitude to trigger thoughtful, important events throughout the user journey that you can dig deeper into. Firebase/Google Analytics/App Store Connect Analytics are not enough.
Seriously, do not overlook this point. Without advanced event-based analytics, it is not possible for you to understand how users are using your app. Which features get the most attention? Which features are being completely ignored? What does a normal app session look like? These are all critical questions for which you need answers, and the only way to get those answers is through event-based analytics.
I realize you may be concerned that these analytic tools are expensive, and they are. I’m paying $28k per year for Mixpanel right now. However, Mixpanel and Amplitude both have very generous free tiers—Mixpanel allows you 100k monthly users and Amplitude allows you 10 million events per month, both 100 percent free. Take advantage of them now and worry about the pricing later.
I want to highlight two analytics features that are particularly useful for pricing. First, macro trends around purchasing and usage. Shown here is an example metric that I use routinely to find out how many people complete onboarding in the app and purchase a subscription or start a free trial.
This is a macro-trend chart. I don’t see how individual users are going through this flow; I only see high-level stats.
User journeys comprise the second essential analytic. In Mixpanel, for instance, I can zoom in to any user and see what individual events the person has triggered. Further, I can filter this to see how paying users are using the app or how people who have at least 25 sessions (high-retention users) are using the app. Here’s that kind of activity.
After looking at 10 to 15 users, you’ll start to notice usage trends. For example, people will typically open Hashtag Expert a few times a week, generate a group of hashtags, and copy them. Their sessions will last between one and two minutes. I’ve spoken to a handful of indy developers, and one of the most surprising things I learn is how few people have event-based analytics implemented. Hopefully, by now I’ve convinced you.
Also, your analytics must be accurate.For a while, I struggled with having accurate purchase events, and then I met Jacob Eiting and started using RevenueCat. One of the most useful features it has is integrations. I have a Mixpanel integration set up so all purchase events are triggered remotely and are 100 percent accurate.
I would advise against manually triggering purchase events in your iOS codebase because StoreKit is weird, and I’ve never been able to get accurate, locally-triggered purchase events. Also, if the user doesn’t open your app, you’ll be missing events, which is why having purchase events done through RevenueCat is really helpful.
Remote Control Paywalls
You’ll want the ability to control your paywall from a server, which will allow you to make updates without needing Apple’s approval each time. You’ll also want to submit new products to App Review and immediately integrate them into the app without triggering an update. I have a backend that I call my PaywallService™, and it stores some basic user information and endpoints. On app launch, basic user analytics information and advertising attribution are saved to this backend. Then, based on that data, a “paywall” will be returned which is essentially a JSON blob.
Here’s an example of a JSON paywall in my backend service and how it controls the behavior of a paywall in the app.
Let’s break that down a bit. Offering ID corresponds with a RevenueCat offering, which means at any time I can submit a new product to Apple, configure it on RevenueCat, and start showing it to users. Pricing text is a string that’s used to describe how the pricing is written (not shown in the above screenshot). Cancel behavior determines when the cancel button appears.
Your implementation doesn’t necessarily need all these parameters and can look totally different from mine. The key here is your ability to remotely control important elements of your paywall, especially products, so you can dynamically enable new products.
Surveys
Two surveys you should regularly be conducting with your users: a product-market fit/general feedback survey and a pricing survey.
For the product-market fit survey, you can ask any range of questions, but your goal is to get general feedback about your product. If you have outrageous pricing, you will start to see that kind of feedback here. I do a combination of Rahul Vohra’s Superhuman PMF survey and NPS. You ideally want to ping users to complete this survey after they’ve experienced the core benefit of your product.
I do this in Hashtag Expert after the user has copied a certain amount of hashtag groups. I send a friendly, Intercom-like message requesting that the user complete the survey. You can ask users via email, push notification, or whatever method you prefer. The key here is making sure you have a constant influx of survey responses.
You shouldn’t be manually surveying users once a month for this purpose (although you can do it for different objectives). Instead, regularly survey new users as they experience the product so you can gauge first impressions over time and identify trendlines.
For the pricing survey, ask users some more in-depth questions about pricing. I use the Van Westendorp method which attempts to understand users’ price sensitivity. Here are the basic questions:
At what price would you consider the product to be so expensive that you would not consider buying it? (Too expensive)
At what price would you consider the product to be priced so low that you would feel the quality couldn’t be very good? (Too cheap)
At what price would you consider the product starting to get expensive, so that it is not out of the question, but you would have to give some thought to buying it? (Expensive/High Side)
At what price would you consider the product to be a bargain—a great buy for the money? (Cheap/Good Value)
After asking these questions, you can analyze the data to inform your pricing hypotheses. Again, the key is surveying new users at the same point in the user journey. Here is the survey I use. It’s an example, so feel free to go through the entire survey and submit results.
Variables
We’ve established that pricing is an ongoing, iterative process. Before we dive into the variables to test and tweak, I want to highlight an important point regarding testing philosophy.
First, design your tests to be robust and scientific. Randomly decide which user gets the cheaper price or which users only get offered weekly. Give your tests enough time to run and conduct a thorough analysis of the data. Always remember to consider statistical significance for everything you’re testing. What you are able to test depends on how big your sample size is. For example, you’d need a lot of data to find out whether $35/year or $30/year is better. Keep that in mind.
Next, macro-optimize before your micro-optimize. You will make progress more quickly if, before optimizing the color on your CTA button, youtest whether $20/year or $100/year leads to higher revenue per user. Make your tests extreme until you start to notice trends and figure out a successful, optimized system. Then, dial-in to the nuts and bolts of your paywall and flow.
When You Paywall
So when should you show your paywall and how often? I’ll save you some time … always show your paywall on first app launch. You want as many people as possible to see it (as in, “You miss 100% of the shots you don’t take.”) Your paywall should not be buried or hidden. Rather, it should be incredibly obvious to your users that there is a paid tier of the app. If they want to convert, they should be able to do so easily.
I show the paywall on every single app launch. It’s the first thing you see if you haven’t paid. I also like to dangle paid features in front of the user. You get excited that you can use a certain feature (there’s no indication that it’s a premium feature), and then after you tap it, I show you the paywall and I highlight the value of that specific feature. You can go even further and let the user use a certain feature a few times and say “This is a premium feature, you can use it two more times for free!”
I’ve noticed that many indy apps and indy developers are shy about showing their paywall. You can figure out where on the spectrum you fit from pushy/annoying to hidden. I tend to lean toward the pushier side because I’m trying to grow my business and every dollar counts.
What You Paywall
You also need to decide where you want to be on the spectrum of pricing aggressiveness. My general advice is to be pushier with the features you make premium, and make your free tier as barebones as possible. How your paywalling techniques are perceived is solely dependent on your messaging and brand. For example, if you advertise your product as a premium, elite app that clearly costs money, people won’t be mad. What will make users mad is if there’s a disconnect between expectations and reality. If you make certain features premium and get pushback from users, that doesn’t necessarily make you an asshole. Chances are, your messaging wasn’t clear enough for customers.
This is another space where you can dig into your event-based analytics and see which features high-retaining users are using. If you make your app free to start, you’ll have a good sample of users to dig into. Analyze the most popular features and put those behind a paywall. (Obviously, you should always grandfather in legacy users with free access if they were told the app was free).
One of the easiest ways to start making a lot more money off your app is to paywall everything—meaning, users only get access to a demo version of your app if they pay. They can poke around or use some features a limited number of times, but there is no free tier on the app.
One benefit of this approach is you’ll get a quicker signal on whether people are willing to pay for your product. If all features are premium. you eliminate the possibility of paywalling the wrong features. This will allow you to make substantially more money, but you may get some bad user reviews and it may not be in your best interests. For example, in Hashtag Expert we benefit when more people are creating hashtag groups, so it doesn’t make sense for us to paywall everything. Your app, however, may not benefit materially from free users.
Pricing
In terms of how to choose the actual price of your product, I suggest leaning on your pricing survey data. Determine the general range people feel comfortable with, and then pick a number. Check out what competitor apps are charging. You’ll want to be in the same ballpark unless your positioning is totally different.
Generally, it’s best to focus on extreme test cases until you figure out your place in the market. Your pricing decision, for instance, should not be between charging $30/year and charging $35/year—but between charging $30/year and $90/year, or between $5/month and $30/month. This is especially important when you have a limited sample size.
When you have thousands of new installations a day, suddenly you can get meaningful data from micro-price tests. Be aware of statistical significance and use a tool like this to analyze your data and make sure you aren’t fooling yourself. You are really trying to figure out the price elasticity curve of your user base. At what price does your product become so expensive that it feels premium, but not like a rip-off? Again, this is where the survey data can provide valuable clues.
Plans
I’ve found in my testing that offering more plans helps increase average revenue per user. In other words,offer a weekly, monthly, and yearly option so there is something for everyone. I typically make my yearly options significantly cheaper than weekly and monthly. I do this because my business is bootstrapped and I have bills to pay. I need as much money upfront as possible, which means I want as many users to choose the annual option as possible. Otherwise, I’d have to wait a number of weeks or months to get an equivalent amount of money.
Likewise, you need to think about your business’s cash flow needs and your subscription churn. If you are confident that you could keep a weekly/monthly subscriber retained long enough to make more than you would from a yearly subscription with that person, and you don’t need money upfront, consider encouraging a monthly option.
Big SaaS companies offer much slimmer discounts on yearly versus monthly subscriptions because they know their churn is really low and that they have plenty of money in the bank. They’re willing to wait the extra 12 months to get 20 percent more money from you.
Apps are usually not in this bucket, which is why you see such big disparities in monthly versus yearly pricing. Most app companies need you to take the yearly option. That way, they can pay off their advertising invoices at the end of the month, and then reinvest all that money upfront to grow the business even further.
That’s why my yearly subscription is the cheapest.
Free Trials
Free trials are a powerful way to incentivize users to choose specific plans. For example, if I offer $30/year with a seven-day free trial or $3.99/month, most users will choose the yearly price. Why? Because of the trial period, which gives users the incentive to convert to the yearly subscription.
Viewing the free trial as a tool in your toolbox is important when you’re thinking about what to charge and what you want people to choose. I suggest only offering free trials on the plans you want people to choose. If you genuinely don’t care if users choose weekly/monthly over annual, then feel free to offer a trial there as well.
Some other thoughts. I haven’t noticed a big difference in conversion rates between three-day trials and seven-day trials. Seven days feels like a good length of time that balances my need to get paid quickly and the user’s need to have time to explore the premium features.
Sometimes it makes sense not to offer a free trial at all. I do this for some of my paid advertising campaigns and it works really well, although the main reason I do it is to make it easier to calculate ROI for a campaign on Day 1. I normally think it’s a good practice to offer a decent-length free trial—and remember, you can use it to influence user decisions.
TLDR;
You should view app pricing as an iterative process. You need a toolkit in place so you can properly measure your pricing strategy’s success and make informed hypotheses. Then, constantly test your paywalls and pricing by tweaking certain variables, including prices, free trials, what you paywall, when you show the paywall, and others.
If you made it this far, thanks for reading. I put a lot of time into writing this. Make sure you Subscribe if you enjoyed this post or got some value out of it. I write weekly articles and send out my posts to subscribers first.
What should I write about next? Tap the button below to leave me some feedback.