So far, this series has focused on tips for building awesome apps. With good design, sensible login and storage systems, and third-party services and data, you’re probably ready to release an MVP to the store. So what’s next?
There’s a popular phrase when it comes to turning mobile apps into businesses: “build, grow, monetize”. While that may be the order of actual events — you build the app, get people to use it, then make money — it’s important to think of your app’s monetization strategy even before you start marketing your app to jump start user growth.
You can begin planning how you’ll earn money from your app even if you’re not ready to implement anything yet. Lots of successful apps have wildly different strategies — from freemium models to ad support, to direct sales of goods and services. To decide on the right strategy, you need to answer a few questions about your app:
There’s also an important step 0: be sure you’re in the clear to monetize. Remember last week’s post on content APIs? The licenses for some APIs may prohibit use of their content in paid apps or in conjunction with ads. I can’t tell you how many hackathon projects I’ve seen that encounter this issue because people just don’t know, so make sure that you have rights to monetize anything before getting started.
When I was in college and the App Store was brand new, my dormmate built an app called Whale Songs. Whale Songs was a slideshow of photos of humpback whales paired with an audio track of them singing, about three minutes in a loop. He put it on the store for $0.99 late one night, and had made $200 by morning.
I don’t think 200 people would pay a dollar for Whale Songs today — if 200 people could even find it among the million or so other apps out there. But I’ve certainly found plenty of apps worth purchasing: ad-free games like Threes!, utilities like 1Password, and a guidebook app chock full of maps and recommendations that works offline.
I bought each of these because their app descriptions highlighted features that solved real problems for me. If you can offer people a great solution to a problem that they have, you can charge for it.
When we wrote Furni, some people around the office joked that it looked so good we should spin it off into a full time business. We said sure — inventory management is the easy part once you’ve written a pretty front end.
Except, of course, it’s not at all. There is a whole ecosystem of tools that have been created to help you track stock, manage payments and POS systems, and everything else that goes into order fulfillment. If you need an end-to-end solution, you have great tools like Shopify, Woo Commerce, Wix, Weebly, or Magento.
If you’d prefer to handle certain parts yourself and use an API only for payments, Stripe is an awesome choice (and easy to integrate with Fabric); Braintree, PayPal, Venmo, Square, MasterCard and Visa all have APIs as well. Always check the terms of each of these providers, since some of them have specific use cases or restrictions.
That 30% figure can be enough to turn a lot of people away from those routes of monetizing. Ads can be the easiest option, and you have a lot of flexibility to do it right. While ads can be frustrating, the good news is ad providers are just as incentivized as you are to provide a positive ads experience to the people who use your app. Annoyed people don’t click on ads. Everyone makes more money when ads are well designed and well targeted. That’s part of the reason behind the rise of native ads.
You have a lot of options when it comes to ads:
A native ad in Cannonball
We chose to put native ads into Cannonball in part because we were really excited about MoPub’s server side ad positioning, released around the same time as Cannonball. The MoPub SDK’s helper classes made laying out and rendering native ads very easy, but up until that point, you had to ship your app with client side code determining how frequently ads would appear in your list view or table view. Server side positioning was a change that let you update those values from the web — so we could bake a future ads experience into our first release, then turn it on from the web when the time was right, without needing to ship a new version of the app to the store.
At the end of the day, don’t be afraid to experiment a little bit. It may take you a little while to hit on the perfect balance of revenue sources for your app, but it gets you that much closer to making it a real business.
Do you have tips from building your own side projects (or main ones)? Tweet at us using #MobileAppPlaybook!
Curious about the Fabric partner kit integrations? Hear from our PM, Jonathan Zazove.
Did someone say … cookies?