A Developer's Guide To Monetising Your App

Dominic Williamson is an app developer who began his career as a psychology student with no prior coding experience. Within six months of changing to an IT degree, he had produced one of the most successful fitness apps on Microsoft's Windows Phone Store, the Gym Pocket Guide. Here are some tips from Dominic that will help budding app developers make actual real money from their apps.

Money picture from Shutterstock

For the average developer you have three main ways to generate revenue from your hard work: In-app advertising, in-app purchases and paid apps. Here's what I've learned in each area during my career in mobile app development.

In-app advertising

Unless you have a way to deliver relevant ads to your users I would recommend you avoid in-app ads. There are a few reasons for this:

  • Ads reduce screen real estate
  • You give away control of part of your app – particularly impacting design
  • Irrelevant or scam ads can annoy your users
  • Above is Gym PocketGuide and a mock-up of what it would look like with a 3rd party ad container. Immediately the ad breaks the chosen colour pallet and creates a part of the app which delivers messages to users which I have limited control over. My preferred approach to in-app ads has been a custom banner which promotes the paid version of the app.

    In-app purchase

    In-app purchases done well can bring in a lot of money — just look at Candy Crush. There are 3 types of in-app purchases:

    Consumables: Something that is purchased, used (consumed), and purchased again, e.g. lives in a game. Consumables have the potential for the highest returns because they can be purchased an unlimited amount of times by the user.

    Durable: Something that is purchased once and then owned by the user e.g. a game level or the ability to create unlimited custom programs.

    Subscription: An automated reoccurring payment e.g. monthly access to a magazine.

    If you have a feature of your app you want to offer as an in-app purchase then I've found it beneficial to give users a way to preview it. For example, Gym PocketGuide (free version) offers the ability to create custom programs. As a preview, users can create one custom program before they need to purchase the feature. The approach also provides an opportunity to promote the paid version of the app.

    Paid app

    How much do you charge for your app? A common question when it comes to publishing a paid app. Setting the price is one part market research and one part being honest about what your app is worth. If your app has been developed for a specific niche you can charge a higher price, otherwise you'll probably want to stay in the 99 cents - $2.99 range. For Gym PocketGuide Pro I chose $1.99 USD as it was on par with other major competitors and also allows me to run 50% off sales.

    Also note, on Windows you have the option to offer a trial experience with paid apps. This is something you should absolutely implement when building or porting to Windows Phone and Windows 8. The trial is completely up to you how you implement, e.g. limited number of uses, but it counts towards your daily downloads which will help your app climb the download charts.

    For tips on building your first app checkout my previous Lifehacker article: A Developer's Guide To Building Your First App.


Comments

    I am firmly of the opinion that the time for making a million based on selling an app is long since past. Unless you have a churn and burn approach to app development where once deployed there will be no more work/updates/improvements. That's the sort of leap frog approach that seems to drive a lot of app development in the current climate unfortunately. It does mean the quality you see initially is the quality you can expect, meaning that poor quality that doesnt earn as much isnt as likely to develop another as a higher quality one. That plus the expectation of quality might be the only things setting benchmarks for development.

    There are substantially more options for monetizing applications but would require more deep dive than just lumping them all together as apps. Affiliate/strategic relations, gamerfication, even the sale of data are common practices now for revenue of applications.

    Good advice, Dominic. With a good quality app that offers a a reasonable amount of basic (free) functionality , I don't have a problem spending a few dollars to get the additional features - simply because I've had time to evaluate the basic version and determine whether the quality of the additional functionality is worth buying.

    I much prefer doing it this way than buying the app outright without trying it first, and then having to apply for a refund if not happy. I prefer to buy the app outright rather than take out a subscription.

    Thanks for the breakdown of types of products to sell as in-app purchases. My app will offer all three types and presently I'm looking for the best way to implement a robust in-app purchase system.

    My consumables and durables are pieces of software hosted on Firebase. I'm thinking that FoxyCart might be an option but hooking up the solution I need is still not there. Basically, I want users to be presented with a list of app extensions, which they can checkoff and purchase. Each users account would then be updated with licence data. The authentication process would then validate the users rights to use their purchased extensions.

    Where can I learn more about this kind of a software goods purchase flow and how to implement it?

Join the discussion!

Trending Stories Right Now