Mobile AppsJuly 25, 2011
This winter, I submitted my first mobile app:
Baby Names for the PlayBook. My motivation was getting a free PlayBook, but it was also nice to learn something new. I set the price of my app at 99 cents. When the PlayBook launched, I was surprised to hear from a user within a couple days. He was from British Columbia, and he had purchased a PlayBook around the same time his second child was born. I hadn't even had the opportunity to run the app on a real device yet, and he was emailing to let me know that on the actual device, scrolling didn't work properly. A week or so later when I had finally received my free PlayBook, I fixed the error. For the next couple of months, my revenue rate worked out to around 15 cents per day. Paltry, and not unexpected. But I didn't care, because I had my pretty new PlayBook!
My uncle Tim expressed some interest in the business potential of mobile apps. I shared my honest opinion with him, which was that mobile apps seemed like a very sketchy opportunity. My sense was that a few apps reaped most of the revenue, while most of the hundreds of thousands of others got little to nothing. Even if you were able to make an app in 10 hours at 40 dollars per hour, you'd have to get about 600 purchases before you broke even on your development costs. And that's about as cheap as an app gets.
Regarding the PlayBook offer, I had offered to write people apps if they had an idea that they were interested in submitting to App World. One such application was Graham's app, Solicit. Fast forward a couple of months, and he mentioned that he had accrued a rather impressive 700 downloads, albeit without charging for it. He decided to spend a few hours and re-skin the application to look nice, and add a couple of simple features that users had requested. He submitted his app in early June and I was rather surprised to hear that money was coming in each day as people bought the app. Fast forward a month, and the app has a revenue rate of about $70/month. While that's a pretty tiny sum of money, some simple math shows that it could work out to be a very lucrative compensation: If the revenue continues for two years, the total revenue would be $1700. Given 12 hours of labor to produce the app, the hourly rate would be $140/hr. Yikes! If the revenue only continues for 1 year, we're still talking $70/hr, which is still great.
Also in June, I implemented my Baby Names app for BlackBerry phones. Again, I did this without any money making intentions, I was just interested in learning some new skills and having some fun. I released the app around June 21. Like with Solicit, I was surprised to see money coming in each day. I had some fun experimenting with the price, raising it by a dollar every 10 days or so, to see how that affected the revenue rate. I settled on $3.99 after a few weeks. In the first month, the revenue rate has been around $150/month, which completely blows me away. Again, not because it's a great sum of money, but because an app with 0 marketing and 13 hours of implementation effort (which would be more like 8 hours if it weren't my first BlackBerry app) has the potential to compensate at a rate of $275/hr if sales continue for 2 years, or $400/hr if sales continue for 3 years. And that's if sales stay steady. What if the app catches on via word of mouth and the sales rate goes up by a factor of 5?
Needless to say, in the space of a month, my attitude towards mobile app development has been turned on its head. It's not that I think it's a fool-proof way to make money, far from it... it's that I see the potential, the possibility.
I'm not one for get-rich-quick schemes, but after doing some math I may have stumbled across one which seems more likely to me than anything else I've heard. It builds on the idea of building apps similar in complexity to what I have created so far, about 6-8 hours per app for programming effort, and 3-4 hours per app for visual design.
The idea is to crank out one app per day, each day, for one business year. One person would do the programming, and another person would be responsible for adding as much pretty visual design as possible in the allotted time. The average time input per app would ideally be about 10 hours. The target revenue rate would be >= $1/day on average, but hopefully >= $2/day, with revenues continuing for 2-3 years. Compare these revenue rates to the first two apps we've done, which are bringing in $2.30/day and $5/day, respectively.
So how much money would this amount to if everything went swimmingly, and apps averaged $2/day on average for 3 years?
230 apps * $2/day * 365 days/year * 3 years = ...
... wait for it ...
$503,700At 10 hours per app, that works out to $219/hr.
And with 230 apps in play, there is a chance that one or two of them could really grab the imagination of the public and go viral. Not likely, but quite possible if your ideas are good enough and your execution is good. Who knows what that would mean in terms of revenue, but it's a fun thought.
Anyway, kind of crazy. You might say "but 230 ideas, that's not realistic". You're quite possibly right, but remember that people like me looove to dream up ideas. I already have a list of 100 ideas. But yes, let's not kid ourselves: This is very far away from a for-sure idea... quite possibly most of the apps would fall flat on their face. But interesting to consider, very interesting to consider...
Baby Names WebsiteJuly 25, 2011
I created a little web page for my Baby Names mobile app now that it is available on three different app stores. I also created a Facebook page so that I could have a Like button:
http://www.danielbigham.ca/babynames/Fun stuff. I should write a blog post about my recent mobile app thoughts and experiences.
Tech Wishlist: Data BackupsJanuary 21, 2011
I wish there was an elegant solution to data backup built into operating systems. I create data, store it in various places on the hard disk, backup some of it occasionally, and then when I get a new computer I burn a bunch of DVDs and try to backup everything. Once my new computer is setup, I don't usually bother to restore everything because I don't want to clutter my new system with things I probably won't need. There are a couple problems with this:
1. | Because I don't backup frequently, and because my coverage is spotty, there's significant risk of losing data. |
| 2. | Because I don't restore everything, and because the organization of my backups is mediocre, even if I wanted to find some old data, it might be extremely time consuming. |
It's not really clear to me how to solve this problem, but to summarize my wish, I want a system for storing that that:
| 1. | Makes backing up automatic so that there is very little risk of losing data and doesn't require remembering to run the backup or the time involved in setting up / performing backups. |
| 2. | Readily searchable so that years in the future, finding an old document is relatively painless. |
| 3. | Doesn't run the risk of "expiring" the way physical media can do. ie. DVDs only last so long, etc. |
| 4. | Is off-site so that a fire (etc) doesn't result in losing everything. |
| 5. | Makes setting up a new computer "painless" with respect to "restoring" data. |
It's pretty clear that the cloud is an important piece of this puzzle, so perhaps that's why this either doesn't exist or isn't in common use. That, and lots of bandwidth. Perhaps the biggest challenge here is the organizational aspect. ie. It's nice when you get a new computer not to have the clutter of the old one, but if your data repository lives forever in an integrated fashion, then you don't get that nice clean start. So the question is, how can the OS / data repository encourage really good organization of information and purging information that is no longer pertinent, etc? That sounds like a pretty challenging problem to solve.
older >>
