I thought this paragraph was particularly insightful:
"I learned a lot from releasing my first iPhone app: Six-Pack Equivalent Calculator... primarily that you shouldn't release an ad-supported app that does not have high user engagement times. The app was a utilitarian "one use and quit until you want to use it again" type of app. I can see an RSS reader or a Facebook client being free with ads, since there's a long user engagement period, but this revenue model simply didn't work with my application type."
It's a pretty good 'rule of thumb' on when you should or shouldn't consider ads as your monetisation method.
I'm reminded of some stellar advice I read years ago -- to launch a new software product, just hang out in the forums of a group of people focused around a topic / hobby / area of passion.
Ask them what they need. Build it.
This doesn't minimize all the work that goes in, but I think it's a great practical reminder that building for an audience with a need is the first step of product management and product marketing. When Amazon launched the original Kindle Development Kit, I posted in ebook forums asking for 'requests' for apps. I received many, many pages of really pretty good ideas for applications.
I couldn't build any because Amazon turned me down for their early-access program, but I was gratified to see how much time and energy enthusiasts put in to helping design and spec an app.
So I read through the whole account, and the whole original thread on logopond. And hindsight is always 20/20, so take this as you will.
First, you never asked if people would pay. I only saw one mention of money exchanging hands in the thread, and it was from someone saying that they wouldn't pay unless it had been proven rock-solid from a legal perspective.
Second, how many people actually landed on the signup page during the time you had the beta up? I think devs often hit the trough of despair and rush to add new features, when the real problem is that they just don't have enough people coming in the front door.
Sorry it didn't work out, though. What's your next project?
That's off the point. Virtually no one who asked or cheered for the service ended up even trying it. I conversed with many designers privately beforehand and they were unanimously saying that - yes, this is something that I've been waiting for and something that I would personally use a lot.
The takeaway here is that the community validation of an idea may not meaning much, even when it is very explicit.
I see what you're saying. You're saying that it's a moot point because you asked if they would use it and they said yes, but then they didn't actually use it.
But the thing you have to guard against most in customer development is a false positive (am I using that right?), where people say they will sign up, buy, whatever, but then they don't. So anything you can do to get closer to a fully validated yes is worth it.
Lots of ideas are neat and things I might say I'd use, but will I whip out my credit card and give you $20 / month or whatever? The ideal is to get a commitment to pay before you build (prepay, pay $1 for the beta, kickstarter, whatever).
However, I think if you had really asked that question and really hammered whether they'd PAY, you might have gotten a little more honesty about whether they would actually value it. You wouldn't have gotten perfect honesty, but I bet the enthusiasm would have waned significantly if you had asked "would you pay $20 / month for this" instead of "would you use this".
But sometimes it just sucks and it goes wrong in the end no matter what you do.
I'm working on a project that's very similar in terms of stage, needing to be validated, uniqueness, etc. So my plan is to reach out to a ton of people, see if they have the problem, see if they'd pay for the solution, and then build a landing page with a giant price on it and see if I can get people to click on the sign up button. Before I write a line of code. I'm tired of building things no one wants or will pay for.
That is why it is better to get a website way before development begins and get interested people to provide their email id to be notified of your launch. This will provide you an early indication of whether to continue or quit.
Ask them what they do. Ask them what they want. Distill that down to what they need. Build it.
People regularly don't know what they need but if you ask the right questions you can figure out what is actually important to them and what is stuff they think the need but actually don't.
My business partner makes over $120,000 a year with just three apps in a very particular field where a limited number of users are willing to pay 19.99 for it.
Don't just join the 99c app game -- if you are looking at joining the app market, examine what unique expertise you can bring to it and target a niche.
Speaking as an iOS dev with a couple apps in the works (one done and ready to submit, one in development), the issue I see with that is that it seems to be higher risk. What if I pour so much time into this super-premium app and then it doesn't sell? Whereas I can do five .99 or 1.99 apps in the same amount of time.
But then I think about how crowded the app store is and how bad discoverability is, and maybe going after a super-small niche with a high price is actually the only low-risk strategy left (long tail). And maybe since it's so niche, you win just by showing up, not by building a super premium app. Which then begs the question of how you find ideas like that.
I'm rambling, but I'd love thoughts from those who have dabbled in the tiny-niche-but-high-cost model on the app store.
> What if I pour so much time into this super-premium app and then it doesn't sell?
The advantage of being able to set the price dynamically will let you experiment. What I've found is that holding the quality of the app constant, you can experiment with the pricing. You might get 10 sales at $5 or 50 sales at $1. If you believe your app really does provide $5 worth of value, it will probably sell. If it doesn't you can experiment with the pricing. It's only "super-premium" if users think it is.
>> Whereas I can do five .99 or 1.99 apps
I'd discourage going this route. For most people this will make more money ... Wait! Don't stop reading. What it won't do though is increase the quality of the applications you put out. You'll end up with 4 or 5 mediocre apps in most cases that roll on getting a few bucks a day. You might get lucky and have an app with better sales, but it's not the same as a rockstar performance by one app. OP's example is a good illustration of this.
>> win just by showing up, not by building a [great] app.
Nope, that's unfortunately not how it works. Sorry. You can win by executing on idea that you have validated. It's much like a startup.
>> how you find ideas like that
You see a need and you fill it. I think that's the best way to put it. Since I can't really help you find an idea, I can tell you this much, you should validate your idea first if you want to reduce risk.
Thanks for your comments. I just wanted to clarify something:
win just by showing up, not by building a [great] app
This is explicitly NOT what I said. I don't think you can win in the long run without creating something great, but great and super premium aren't the same thing. I've bought apps for $1.99 that were great that I would never have paid $19.99 for because they just didn't provide that much value. So what I was trying to say was that if you're going to try and create something worth $19.99 in value, you can either pick a saturated area and try to be the super premium offering, OR you can pick a completely underserved but hungry niche and create something good that solves a need.
> Which then begs the question of how you find ideas like that.
One option is to go after a professional audience, i.e. create apps that are likely to be paid from a corporate account. Look at LogMeIn - they have a remote desktop access app aimed at sysadmins and it sells for $99 with 5 star rating. Look at Office-like apps - $10-$20 a pop and they sit firmly in top grossing charts. Anything useful that qualifies as a business expense just begs for a higher ticket price.
The good news is that you don't have to choose. Launch at $0.99 and look for huge exposure. If that happens, great! If not, you can experiment, get a sense of what the elasticity curve for that particular app looks like, and price it optimally.
Yes. This is probably the biggest mistake that people make as newcomers to the app store. If you believe that your app is worth $X, you should be charging $X.
Unrelated: I see that you helped the Freemont Unified build an app. A guy on the board of directors there helped me get off the ground on creating education apps, are you still working there or was it a one-off project?
My experience with our educational app is that we actually sold less units(!) when we tried going down from $3 to $1 - we changed nothing other than the price so we have to assume our target group (teachers, mainly) is more attracted to apps > $1 - presumably because they assume them to be higher quality (and may actually be right about that).
Has anyone had a similar experience?
A lot of success can come from creating simple apps for undeserved niches. I've made about $10,000 over last two years selling an app that is literally 5 images in a tab view. It took me one weekend to make. I know it's not too much, but it feels good in the pocket, the money flows steadily every day no matter what and requires absolutely no maintenance or additional work on my part, ever. There's a lot of low-hanging fruit in the long tail of the distribution.
Thanks so much for posting! I think the real key here is that you went after an underserved niche, instead of trying to build something with mass appeal. The app store is crowded for sure, but there are still tons of underserved niches out there just waiting for a good app.
Completely offtopic: You are using cloudflare. Please Don't!! They use an IP blocklist and block legitimate readers like me. See this screenshot. https://img.skitch.com/20120110-xfpmpw5rww8fajf13a73hm1k3u.j... I use a mac and I'm blocked because there could be a virus in my computer or network??
Handing out business cards for the app at the convention was a smart move. It's amazing that doing something so simple can be so effective yet I find myself getting stuck in the mindset of trying to fix things digitally. Get out of the house!
Thanks for posting that. I'm in a similar situation with a couple of apps that have done surprisingly well, and am hoping to replicate their success on other apps.
I especially like your marketing idea: qr codes on business cards handed out at a conference. Glad it worked for you!
Thanks! (original author here). Incidentally, there's ANOTHER industry conference this weekend. I got 500 business cards printed up (double sided with both my apps) to hand out. Other than that, Facebook is the only other real "marketing" I've done.
Do you know if anyone actually used the QR codes? I don't know anyone who has actually used one. Did you have a way to check if it helped having a QR code on there? Or do you think it was you talking to them and your business card that closed the sale, rather than the QR code?
I handed out about 200 cards that weekend and there were about 3 people that scanned the QR code and bought it on the spot (right in front of me... now THAT was cool).
Keep in mind that this is 95% women in this industry, so I didn't expect them to be as "tech savvy" than if I was at a computer conference or something.
I believe that the personal touch of saying, "I built this for someone like you" has a HUGE impact on how people feel about your brand and your app.
Almost... it sent them to my linkshare link that then forwarded them to iTunes (which opens the App Store app on a device). So i gained back that 7% of revenue from Apple that my linkshare referral program gives me. Sneaky, huh?
I've found it can do a lot, especially if your app is for a niche market like the OP's. When you go to a conference or a trade show, you're surrounded by people who will buy your App. It doesn't get any better than that when it comes to marketing. Good reviews only help if people find your app on the app store to read them.
A good start would to get App Review sites to review your applications. It depends on the category of the app, so if you don't mind me asking, what type of app is it?
Thank you for sharing, its appreciated by people like me who are new to mobile development.
Question: Can you disclose any information about your in-app sales? You mentioned you sold customizable background art, what was the price point? How many did you sell? Roughly what percentage of app owners end up doing an in-app purchase?
----
No problem. Those are some pretty complex stats, but I'll try and simplify them for you.
Total In app purchase revenue to date: $460.73. That came from 545 total transactions averaging out to about $0.85 per transaction ($1.22 before Apple's cut). I have some art that's $0.99 and some is $1.99, but nothing over that. You can see the percentage of the whole by looking at the last graph. Anything at the bottom of Sept-Dec that isn't that large maroon color was an in-app purchase.
During that same time frame, I had 3,007 purchases of the app, which means on average, 18% of my users made an in-app purchase (not taking into account users that purchased more than one item or users that upgraded from previous versions and then bought an item). If I take into account my total user-base of 4,748, then about 11.5% of users made an in-app purchase so far.
As I understand it, the in-app purchase for a game like Jetpack Joyride hovers around 1% or so (read that somewhere, can't remember where). So 18% and 11.5% are pretty dang high in-app purchase numbers.
----
I wonder if the author changed the title or keywords when he shipped version 2. That's one of those hidden factors that can make a big difference in sales.
(Not to minimize the importance of word of mouth and a great product, of course.)
Hey Phil, I don't remember WHAT exactly I changed in the keywords from version 1->2, but I'm pretty convinced that making the app prettier and easier to use was a key factor in the growth in popularity.
Keywords are one of those things you don't think about right away, but they can have a HUGE impact on search results in then end.
I'm curious - if the UI has changed - are people just picking this up from screenshots? With no trial mode, I'm interested in how you think improvments in the software improve sales. Note that I totally agree with this position, but I'm curious as to how this plays out on App Store purchases.
I agree with markrickert on this. Apps that look prettier and work better (usually) have more sales. And improving those things (usually) improves sales, as far as I've been able to tell.
Screenshots are part of it. Word of mouth is also a big factor. If people actually do like your app you'll have positive reviews -- it's commonly said that reviews/ratings don't matter, but for some apps they seem to matter quite a bit.
Most of the apps I write use transient data loaded from a server, so I download and cache the JSON from my server locally and build the tables, etc. that way.
I haven't delved into CoreData just yet. It looks daunting, and I've only been doing this for a year, but it's next on my list to learn.
Check out my github account for some of my iOS stuff. (my username on hn = my username on github)
Thanks, but I am a little lost. I take your answer to mean the Checkout Helper app uses JSON to read from a database for the column of prices and discounts, but how is it cached locally?
I am just wondering how to do something similar in an app I have built, calculates a column of numbers, but in a different knowledge domain from your app.
Ahh, that app doesn't actually use any web services other than for the in-app purchasing.
The numbers that are calculated are from direct user input, but the things that are stored like shipping and tax rates are stored using NSUserDefaults.
Caching data locally is fairly easy... just put the downloaded JSON file into the application's sandboxed /Documents folder for easy retrieval later.
Ah-ha! I just assumed the "Your Items" list was saved, but it obviously isn't. I write my apps to saved the input lists. My assumption is that the user wants to preserve the list items for future usage. Maybe it is more than needs to be done.
I am in fact saving the list so the user can have history of what was entered and then they can name the transaction, duplicate and restore transactions. I'm just using JSON to save the history. I tested up to 100k records and didn't see a slow-down in performance so to deter me from doing it that way.
Best possible solution in a perfect world? No. Works? yes. Works well? Yes.
That's a good question. I guess the answer depends on if you can find enough underserved niche markets that you know enough about to create something unique and special.
And remember, that $10k was in 6 months. So potentially, we're talking about $20k/yr for this app. 10 apps would be a potential $200k a year.
Right now, I'm content with this being supplementary income, but I never imagined that when I paid that $99 developer fee that I'd do so well.
I know i'm a bit late on this, but here's a PRIME example of someone using the shotgun effect in the itunes store: http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewArtist... 504 apps all with slightly different title and keywords, all with sub-par execution (based on looking @ screenshots)
I think their company name says it all: "FQ Publishing"
The answer just has to be "yes", subject to the number of party-based network marketing type operations, especially those for "soft-goods" such as semi-precious jewelry, soaps/toiletries, candles/ornaments, lingerie/(err)novelties, etc.
Hostessing these sort of deals successfully takes a lot of prep and work up-front, during and after to make sure it runs smoothly, customers are totaled up correctly, orders placed, items delivered etc.
There's likely a wider scope for checklist and CRM-type apps...
"I learned a lot from releasing my first iPhone app: Six-Pack Equivalent Calculator... primarily that you shouldn't release an ad-supported app that does not have high user engagement times. The app was a utilitarian "one use and quit until you want to use it again" type of app. I can see an RSS reader or a Facebook client being free with ads, since there's a long user engagement period, but this revenue model simply didn't work with my application type."
It's a pretty good 'rule of thumb' on when you should or shouldn't consider ads as your monetisation method.