This section lists all blog posts, regardless of topic.
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.
BlackBerry PlayBook ... The Rough EdgesMay 12, 2011
Now that I've had a couple of weeks to use the PlayBook, here are the rough edges that I've come up against. (Some perhaps are software/hardware issues with my phone)
  | The most challenging issue has been the Bridge functionality. To kick things off, one day, I was no longer able to initiate a Bridge link between my phone and PlayBook. I tried again and again, no luck. Then I tried deleting the Bridge link and recreating it, and go all sorts of weird behavior. When I'd go to create a new link, the communication between the phone and tablet wasn't quite working. Sometimes it would start to work and then fail. After lots of bizarre behavior, I restarted the phone and it started working again. Since this time, it has not been rare that, again, Bridge stops working and I have to restart my phone. Maybe this is related to faulty phone software or hardware, though. (BlackBerry Bold from 2009) |
| Internet tethering will drop off and disconnect while I'm in the middle of using it, and then like Bridge, will refuse to reconnect at times until I reboot the phone. |
| This isn't a PlayBook issue, but I've found that sometimes when I reboot my phone, it goes from having almost 100% battery to having < 1/5 battery. What on earth? So you go from tethering on a fully charged phone, to tethering disconnecting and refusing to connect, forcing you to reboot the phone, resulting in an almost-dead phone. Ugh :( |
| To make Bridge and internet tethering pleasant to use, I need to keep Bluetooth enabled on my phone. (It's no fun to have to fish your phone out of your pocket and fumble around turning on Bluetooth every time you simply want to check your email on your tablet) But it seems like keeping Bluetooth on drains your phone battery much faster, so you're smart to keep Bluetooth off. We have a conflict of interests here, and it's not a particularly happy situation either way you play it. |
| Bridge functionality works decently, but my one complaint is that applications start slower than they should. It's excessive to have to wait 5ish seconds just to peek at your email. |
So while I'm not bothered by the Bridge concept like other tech reviewers were, the realities of it right now with my particular phone are pretty rough around the edges. We shall see whether this improves at all, and whether native email clients resolve the need for Bridge.
older >>
