Published: June 22, 2009

• Introduction
• BlackBerry Platform
• Development
  • Look and Feel
  • It's the Network
  • Background Apps/Memory
• Pricing the App
• DRM
• Selling the App (Retailers)
  • Handango
  • Direct
  • MobiHand
  • BlackBerry App World
• Initial Sales
• Marketing
• Sales Post-App World
• Dealing [or not] with other companies
• My Customers
• Conclusion
• Topic Outline

Introduction

This article attempts to relay my experiences and lessons learned in the making of PodTrapper, my first mobile application for BlackBerry. It will cover development, pricing, marketing and sales in addition to other items I thought were relevant.

It all started in November of last year. I'm an avid podcast listener during my commutes, and at the time the only viable way to listen was to tote around my iPod. But I still needed my BlackBerry for work, so I was stuck with two devices. I had been toying with the idea of writing a podcast player for BlackBerry and with the announcement of the App World it was now or never. I'm hoping that the success of the iPhone App Store will enable other platforms to follow suit. Afterall, BlackBerry currently has more users and is shipping twice as many phones, albeit to users that may not know apps are available for their phone... yet. Plus the whole project sounded like a lot of fun.

I've read all the stories about iPhone developers making fortunes selling apps, how that may not really be the case, or even that people don't even use the apps they download. I assumed that the truth was somewhere in the middle, but at the very least I wouldn't have to carry two devices anymore.

So I bought myself a set of signing keys ($20) and went out to RIM's developer site to grab their SDK. That's when I ran into my first problem.

The BlackBerry Platform

All BlackBerry phones are java based, and there are two SDK options for developing software on them: MIDP/CLDC and BlackBerry specific APIs. The generic MIDP/CLDC route would work on any java based phone (or at least could be debugged on any java phone). Or you can opt to use RIM specific APIs that give you more BlackBerry specific functionality. Initially I leaned towards CLDC to maintain portability, but I eventually decided I'd rather take full advantage of the platform. I could always port it later if it came to that (if there is a later).

Great, now I just needed the RIM SDK. Turns out there are about 5 different versions, and the more features you get the fewer devices you can support. RIM has been around for a long time, and unfortunately (and unlike the iPhone) not all operating system revisions are available for all devices. The basic choices when I started PodTrapper were 4.2, 4.2.1, 4.3, 4.5, and the newly released 4.7. While you get more features with the later OS versions, I decided to shoot for 4.2.1 since it was the oldest version that allowed me to access WiFi networks, a major feature I needed. There were revisions prior to 4.2, but they lack even more required features like access to a media card. To give you an idea how many users you'll lose based on your target OS, here's data from PodTrapper's users:

Similarly, here's the device breakdown:

I have a suspicion that the vast majority of BlackBerry users out there are actually running 4.2.1, the OS that shipped with the original Curve and Pearl. Because PodTrapper users are likely heavily biased toward the tech savvy side, my users are more likely to have upgraded their OS than an average user. I'd be interested to see what the numbers look like globally.

Development

Look and Feel

I envy the iPhone developers out there. From what I understand the iPhone SDK provides all sorts of pretty widgets that come pre-made to fit in with the platform. Right out of the box you get a clean UI that looks 'modern'. To put PodTrapper 2.0 in the same league a significant portion of the code is dedicated to drawing lines, bezier curves, bitmaps and shading rectangles in just the right way. The built-in widgets like Screen, ListBox and TextField look a bit like this:

It's a very no-nonsense, get the job done set of UI elements. Anything you want on top of that you'll be building yourself in Java using very basic primitives. Another contrast with the iPhone is that on BlackBerry you have to accomodate multiple screen resolutions. This means you end up either shipping with a lot of redundant artwork or you need to resize your images on the fly. The built in image scaler is designed for speed and memory, but the tradeoff is quality. An image scaler for the thumbnails is one more thing I had to build to keep the install size down. Each image increases an apps install size, which on most devices is a very precious commodity.

Versions 1.0 - 1.9 relied on the built-in widgets, and I had originally planned to keep it that way. The reasons for this were A) I wanted to focus on features more than polish, B) It's a lot of work to make it look any particular way and C) I suck at making things look good anyway. I realized, though, after getting my first reviews, that I couldn't get away with neglecting appearances if I wanted to attract users. Many dismiss applications based on appearance without even getting to the functionality. I was hoping to avoid this for my 'hobby' project, but I saw the growth potential if I paid attention to the gloss. It seems no amount of behind-the-scenes wizardry can compete with "Ooooh! Shiny!" <sigh>.

Since I knew I wasn't going to stop sucking at graphic design any time soon I started looking for options that didn't involve me picking colors. I wasn't comfortable copying some other application's design work, so I needed to look at outsourcing. I started my investigation on Google, my forums, and Craigslist. In the end I never found a fit. This was, in large part, because my budget was limited. Being a hobby project I didn't want to invest thousands of dollars and watch it flop. In the end RIM solved my problem for me when they released the App World. Any BB users reading this should recognize that my current look and feel is almost identical to the App World. I figured copying RIM wasn't really ripping them off, more like emulating the look and feel of a host OS. To actually make it happen took a LOT of work.

This is a minor beef I have with RIM's SDK. RIM has all sorts of UI widgets they use in their first party applications -- rounded corners, sliding screen transitions, gradient list fields, etc. -- but they don't release any of that for use by third party developers. The results are apps with wildly inconsistent UIs, created by developers who had to spend considerable effort making them inconsistent.

It's the Network

One great aspect of the BlackBerry platform is the availability of the network communication across carriers. Unfortunately it's implemented as a bunch of totally isolated transports that vary by data plan instead of carrier. There are 10 different network transports available on BlackBerry: WiFi, Direct TCP, WAP, WAP2, BES/MDS, BIS, Unite, BES Serial Bypass, USB and Bluetooth. A lot of options for getting data in and out. What would be nice is to say:

What you get is:

Now, granted, there are a lot more ways to talk to the network on a BlackBerry than other platforms. And they're pretty flexible with what they let you do (for example, there are serveral different methods for tethering, some of which will operate regardless of carrier or desktop OS). But, there's a huge learning curve to get it right. Especially since a lot of that learning can only happen when your app is in the field. That's when you find out that Vodafone is running all HTTP responses through a proxy that changes the output. You can't really test that in a simulator. Because my app is heavily network centric it makes sense that I'd have to figure out the nuances, but it can't be fun for simpler apps just trying to submit a tweet.

Background Apps / Memory

A fundamental part of PodTrapper is its ability to refresh your podcasts on the schedule you set. This way they're always available when you want them, much like iTunes would do on your PC if you left it open (except without the syncing). That means PodTrapper needs to be running *all the time* on your phone. Fortunately this is fully supported on BlackBerry. Unfortunately this brings with it all of the aspects you need to deal with when writing long running apps -- memory leaks (yes, even with java), resource limitations, thread based events, etc. For example, some of the earlier versions of PodTrapper (ok, maybe not so 'earlier') would parse feed xml and store data from the xml inside an episode object with String.substring(). I completely forgot that the JVM implements substring as a pointer to the location in the original string. So, if I had a 100k RSS feed, and I pulled out a 100 byte string with substring and stored it, the 100k RSS feed could never be freed. (This isn't exactly what happened, but it's close enough and much simpler to explain).

Making matters worse is the limited memory available on early BlackBerry devices. My curve has 32MB of RAM and 64MB of flash. The flash can be used for paging if it's available, but on my device only about 20MB of it is, and that fills up fast installing applications (PodTrapper alone is 350k). Realizing that the OS and other apps also have to fit in RAM, leaking a 100kb string becomes a huge problem. There are lots of forum posts by people trying to figure out why their phone keeps running out of memory and needs to be rebooted. It's a large enough problem that there are apps for automatically restarting your phone. I can definitely see why Apple has been hesitant to open up background processing on the iPhone. It's really easy for bad developers to make the whole platform look bad.

Pricing the App

Competing apps were, at the time of initial development, selling for anywhere from $20 - $30 (they've since dropped). That seemed high to me for the features they provided and the platform they were on ($30 mobile apps!?). To top it off there were no trial versions available, so basically you were gambling to see if it even worked on your phone. PodTrapper needed to have a much lower price, and it had to have a free trial. I decided $10 seemed like a mental barrier, so $9.99 was going to be what I charged for it. This was pulled directly out of thin air, though, I had no objective data on 'what the market would bear' to back it up. I did know that I preferred people see my app as an incredible value instead of overpriced.

After the first few releases the feature set grew considerably and I contemplated raising the price. In hindsight this should have been done as a result of sales, or market testing, or anything more concrete than "it feels more valuable." The one piece of data I did have was that the same reviewers who invariable critiqued the early appearance also almost universally mentioned that I was charging too little for the app. So, I strongly considered raising it to $12.99. I even went so far as to post about it in my forums warning of the upcoming price hike. Before actually doing so, however, I wanted to get feedback from my existing users. I was blown away by some of the incredibly insightful comments I received, and not a single "This app is a piece of crap, it should be free" post (always a plus).

This is when I started discovering how cool it is to have and correspond with a user community. My users have been the best part of this whole experiment, so much so that I have a whole section about them later.

In the end I determined I had a good thing going and greed was the only thing driving the increase. The one idea I did implement was the concept of voting with dollars for new feature prioritization. That turned out to be a flop. I only had around 4 users actually do it, but it was a neat experiment. (I have also had two users pay twice because they thought I was undercharging. I *really* love my users.)

I also want to eventually offer an ad supported version. I haven't figured out how to make this happen, though, as I outline in the Third Party section later.

DRM

Ok, I had a product and a price, how do I make sure people pay for it? Do I want to make sure people pay it? I decided there had to be some mechanism for ensuring they actually paid for it. The mechanism would be a registration code. One thing that I knew for sure, though, was that if me or my server ever went away they should still have access to their app. But, I didn't want a single reg code to be passed around and used by everyone. So, I decided (poorly, in hindsight) that the optimal solution was to tie the reg code to the device serial number (called a PIN). Yay! Problem solved. Except I didn't think it through all the way. I knew switching devices would be an issue, but I figured that it didn't happen that often, and if a user switches phones every two years, paying for a $10 app again isn't a huge deal. I really need to stop projecting myself on to my users. People change phones A LOT. Phones break A LOT. Was I really planning on making someone pay again 2 weeks after their initial purchase? I decided shortly after people starting paying for it that the only sensible solution was to let people switch devices.

This turned into a huge ordeal because of the various channels they could use to purchase it. I've since implemented a new key system that uses negative confirmation to my server, but I'm still working out the logistics for transitioning everyone to it. DRM is a total pain for all involved.

There are a lot of competing goals here that I haven't quite reconciled yet. How do you ensure that enough money is coming in to keep development going? Why should users have to pay twice for software they purchased soley to switch phones? Why should people who bought version 1.0 be penalized for being early adopters and forced to pay more for 2.0? In the end I decided that updates are free and you can switch devices for free. I just can't stop coming back to the "I paid for this, it's mine" train of thought. I could charge for updates, I suppose, but even that seems fishy, especially since I'm releasing them in small chunks as a way of avoiding massive bug lists upon release.

Definitely something I'll think a LOT harder about with my next app if I have one. For now, though, I'm happy with the current results.

Selling the App (Retailers)

Ok, I had an app, I had pricing, I had [horrible] DRM, how would I find users and sell to them? For 1.0 I was focused mostly on getting it out the door and the only retailer I'd heard of that sold BlackBerry apps was Handango. Of course I'd eventually want to sell through the App World, but it was only just announced and nowhere near fruition. I did some googling and saw MobiHand but decided it must be less popular than Handango since I hadn't heard of it. (Not exactly bullet proof reasoning). So, I went with Handango for my first sales.

Handango

For anyone that doesn't know, Handango charges small developers 50% of sales. There are thresholds you can reach to get progressively lower rates, but I never crossed any. On top of that they run promotions and such where they'll knock 20% off the price of your app. All in all I was making right around 40% of the $9.99 I wanted to charge for each sale. So I was keeping $4, Handango was keeping between $4 and $6 depending on promotions. For comparison, the Apple App Store is a 70/30 split with the developer pocketing 70% of sales. Support-wise Handango was pretty slow to respond to just about anything. I hadn't been paid by them from Nov through Feb, so I opened a ticket. It was a full 20 days before I got any sort of response. Additionally, as you can see by the graphs later, it was by far the worst performing retailer for me. Poor performance and high prices, hmmm. You can see in the sales graphs later I eventually stopped selling through Handango altogether.

Direct

I had always planned to sell direct via my web site, but I had assumed that sales there would pale in comparison to a full service app store like Handango. As a result I delayed getting direct sales working until after Handango. That turned out to be a mistake, since reviewers would link to my site and I'd have to link to Handango and get billed %50 for the privilege. In hindsight direct sales or MobiHand should have been first, probably MobiHand.

MobiHand

After nailing down the direct sales approach I started looking for other avenues to sell. I had seen MobiHand before, but I had only skimmed the surface. When looking for other stores I discovered that a lot of them were actually powered by MobiHand as what they call a 'channel site'. Getting in MobiHand would automatically get me in a ton of others (like the CrackBerry Store). MobiHand also had much more reasonable pricing, an 80/20 split with the developer keeping 80% of the gross. They did run promotions and such that would sell it at lower prices, but I don't know enough to know whether that's a good thing or not for my product. Plus Handango did it too, so at least I wasn't losing ground. The gotcha with MobiHand, though, is that sales through their 'channel sites' like CrackBerry result in an additional 20% cut going to the channel site, leaving the developer with 60%. Still better than Handango. Plus, it seems a lot of the channel sites also run blogs and they're always on the lookout for new apps hitting their stores to tell their users about. It's a great way to get noticed initially.

BlackBerry App World

The App World has been a bit of a trip. The App World announcement is what finally convinced me to write my app. I wanted to get in on the ground floor by having PodTrapper ready for App World's launch. I'm sure the iPhone is still making tons of money for some developers, but with 40,000 apps it seems like it would be hard for new apps to get noticed. Getting in to BlackBerry now is like having gotten in to iPhone early last year. I submitted in February, but wasn't approved until about 2 weeks after launch. Close enough. The fees are great, it's always an 80/20 split, with no oddities like promotions or hidden costs. The browser UI is great, I actually based PodTrapper 2.0 on its look and feel. It's not without issue, however. It feels a bit slow and there's no desktop based browser. Mobile only is fine for now, but as the number of apps grows this will become problematic if not corrected. I've never used its iPhone doppelganger so I can't make a direct comparison.

I did get the feeling they rushed it out to make their April 1st target. For example the registration mechanism on their test site wasn't testing the same inputs and outputs as the production site. This resulted in a lot of early adopters getting registration errors when they purchased apps and developers having no way of knowing what was wrong. Another one of their initial issues was related to network access on some phones and carriers -- networking on BlackBerry is so complicated that even RIM didn't get it right on the first try. I will say their support was excellent via email, usually responding within 24 hours to developer issues.

The approval process takes a couple of weeks at least, but from what I've heard that's similar to the Apple store. Conversely none of the other avenues for selling BlackBerry apps have an approval process worth mentioning, all are welcome. The App World does cost money to get started though, $200. This covers 10 submissions and then you need to pay another $200, so it works out to $20 per submission with a minimum of 10 submissions per purchase. I'm not sure the reasoning there, but it's their store. Some have complained about the minimum price you can charge ($2.99), but that's not a problem for PodTrapper. It may be worth noting that the submission fee was waived for early submitters and I haven't figured out a way to see how many submissions I have left, so they may not have implemented this yet.

The App World does allow trial software, but there's no way to signify this in the app browser other than including it in your title. If I didn't have 'Free Trial' in my title I'm not sure how users would know they don't have to buy to try it (other than the less than explicit download button inside the app details.) I've noticed a lot more apps are starting to follow suit and add the 'Free Trial' label to their apps. This gets confusing for users since after they register and unlock the full version the title remains 'PodTrapper - Free Trial' in their App World 'My World' list. This invariably leads to an email saying "I purchased but it still shows trial" that I eventually worked around with a popup after registration.

Initial Sales

I wasn't entirely sure what to expect after the first release. I knew I had to have some way of letting people know about it, but hoped that most sales would come organically. I had no marketing plan. I did go so far as to post a few notes about PodTrapper in some forums, but that was it. I was getting about a sale a day for the first month, which I thought was cool, but I wouldn't be retiring any time soon. It wasn't until I signed up for the MobiHand store, bringing me to the attention of CrackBerry who wrote a review that I started to see the potential.

Sadly I don't have usage data like the number of active trial users for the first few months -- I didn't implement the update check until mid January (explained later). But you can see from this sales-only graph that I was getting between 6 and 7 sales per day after that initial CrackBerry review. Note that the sales data is a 5 day prior moving average, the raw data is much too noisy to see trends. For comparison, my day-job salary is equivalent to about 19 sales per day or roughly 133 per week. It was after that first CrackBerry review that I decided it may be worth getting serious about tracking and marketing to see what I could achieve with PodTrapper.

The first step was to implement usage tracking. While it's theoretically possible to track downloads and such, the practicality of doing so and merging the data from 4 different app sources (3 actually, the App World wasn't available at the time) would be difficult to build and maintain. One of the features on my todo list was to implement a version check inside PodTrapper to notify users of the latest versions, so I saw an opportunity to kill two birds with one stone. The version check I implemented initially sent back two things: an anonymous id mapped to the install, and whether or not the user had registered. The data sent back grew over time to include things like BB OS version and such, but nothing that could be tied to a user. Additionally the update check was configurable in settings. (Though now it's mandatory since I use it to provide negative confirmation of transferable registration codes).

This simple data opened up all sorts of interesting views. This one, for example:

The above graph shows what percentage of trial users using PodTrapper on any given day eventually registered. It shows that the rate over time is pretty consistent. Early adopters that probably heard about it because they Googled 'Podcast Player Blackberry' or similar would be more likely to purchase than someone who just happened upon a review. That's also likely why there's the intial level between 40 and 50 that has fallen over time to a lower value around 30%. The localized dips are likely caused by blog posts that drive a lot of people who aren't necessarily interested in it long term, but just want to try it out. The power of this graph is apparent when combined with this one:

With those two pieces of data I can do this nifty calculation:

I'm unsure if this is statistically sound, feel free to let me know if not. It's also handy to compare the registration numbers to the number of new trial users on a given day:

So now I had the tools to see what was possible, I set out to market PodTrapper. I just had to figure out how to do that.

Marketing

I got the wrong degree

Initially I only wanted to go the organic route -- let people find out about my app via word of mouth and let the user base grow naturally. The fact that PodTrapper was pretty much the only option for podcast listening on BlackBerry meant my Google rank for relevant key words was really good. I was happy with that and thought it would be sufficient. Afterall, I'd much rather spend time adding new features to my product, not harrasing people to buy and talk about it. But after some reviews and links hit I started to see the impact they can have. Getting a mention on pretty much anything was enough to double or triple my sales and trial downloads over the next week or so.

If there's one thing I would point to as a major lesson learned from PodTrapper it's that marketing is everything (and everything is marketing). I could have created the greatest product unknown to man, but if no one knew about it how could they buy it? This is obvious, of course, but what wasn't so obvious to me was stark contrast between organic and active marketing. For example, I released version 2.1 a couple weeks ago. It wasn't a huge upgrade, multi-playlist support was the biggest new feature, and so I thought "no one will blog about this." But instead of just assuming that, I fired off a few emails letting people know about it. Turns out that a few blogs did find it noteworthy and those four emails that took me *maybe* 10 minutes to type up resulted in this spike:

Had I just released it and let only existing customers discover the update via the internal check it would have been business as usuall, no spike at all. The moral here is that you can only get back what you put in. That's not to say that you'll always see a return, though. Another annecdote: prior to the previous example I started actively marketing to people I thought would be interested in PodTrapper and help spread the word. Take twit, for example. A huge podcast with thousands of subscribers. They'd even dedicated significant time talking about the new over the air podcast downloading ability on the iPhone (which pales in comparison to the features PodTrapper offers, and there are more users on BlackBerry than iPhone). Of course he'd want to talk about a player being available on a new platform on his show!

Except it didn't go as I had planned. At all. I sent out a bunch of these types of emails, each one written specifically for the person I was sending to. The responses were few and far between. I did get a few, but far less than I expected given how specifically I was targetting. I was only targetting people I thought would benefit themselves in knowing about my app (podcasters, tech bloggers, etc). Then I stumbled upon Ryan Block's (of engadget fame) message to PR people (definitely worth a read). I realized these people probably get inundated with tons of crap like my "Hey you may be interested in this cool thing I did" emails. In the end I discovered that while emailing random people can work (afterall, I did get a few responses), it's doesn't always and it's a lot of effort to do it properly. I had a spreadsheet that I used to track where and when I sent something so that: 1. I never sent something to the same person twice and 2. so I could see any corrolations. I haven't figured out a better mechanism for spreading the word yet, though. If you think of anything let me know.

It's probably worth noting here that I still hate the whole sales angle. I spent a lot of time making sure each email or correspondance with someone was specific to them and that I thought they'd have an interest in knowing about PodTrapper. I did look in to 'PR Websites' where you submit a press release and they mass email millions of people, and while I'm sure that would get a response (afterall, someone is providing the ROI on spam) it wasn't something I wanted to do.

Finally, a note about press releases: have one. While some of the larger sites will write their own copy when talking about your app, the majority will be copy and pasting from something that already exists. A press release is a great source for them to do that.

Sales Post-App World

The app world was big for me in terms of marketing. I was accepted into the app world on April 18th, marked here on my trial users graph:

Unfortunately I was accepted the same day 3 or 4 blog posts hit regarding my 2.0 release so the data isn't absolutely clear, but you can definitely see a difference between the pre and post App World averages. If you take out the spikes I was getting an average of 26 new trial users per day before the App World, and that jumped to 76 after. There are other factors like new features, additional blog posts, etc that could be contributing to the jump, but none that could account for 3x. It's pretty clear the App World has made a significant difference in people exploring for apps. Here's the graph of downloads using App World's reporting:

This graph shows why using download counts to measure is sub-optimal. If you compare this graph to my new trial users graph there's a big discrepency. I determined that it's mostly caused by people reinstalling or upgrading to new versions. If I were going soley based on the download count to determine my registration rate I'd be underestimating the actual rate by a large margin.

I still have a suspicion that most users aren't even aware they can get apps for their BlackBerry devices. Hopefully once RIM works out the teething issues with the App World they'll start marketing it and that will automatically help apps inside.

Here are some other interesting graphs that relate to marketing and sales (you'll probably be interested in the sales graph) but about which I couldn't find anything interesting worth talking about. One thing to note is that PodTrapper is really close to a full second salary if this keeps up. First up is my sales over time, the spikes are generally blog posts or similar:

I was curious to see what the patterns were for registration. I'm sure there's some way to use my data to figure out what the optimal trial period is instead of the "30 days sounds good" method I used.

And here's a screenshot from Google Analytics that shows how people find my site. It's not a complete picture of how people find PodTrapper since you can get PodTrapper without ever visiting my site, but I figured it's worth showing.

Dealing [or not] with other companies

One thing I've been frustrated with is getting in the door with other companies (companies other than RIM or retailers). For example, one of my eventual goals is to offer an ad supported version of PodTrapper. I think there's definite value in PodTrapper at $10, but that means there'd be even more value in PodTrapper for $0. To that end I set out to get information from ad networks for my app. Of the 10 or so agencies I emailed, called or filled out an online form for I got one response, and that was weeks later. I understand that I'm small potatoes as a single developer and a small user base (for now?), but no response at all? I'm not even sure what I'd have to change to fix the problem.

Another example is Audible. For those that don't know Audible makes a long format player for BlackBerry. Sort of. A lot of my users have suggested that it would be great if PodTrapper, a long format player itself, could play DRM encumbered Audible files. Great idea, let's contact Audible! Well, I've tried four times now to get anything out of them with not a single response. Not even a "That's not possible, sorry."

I'm obviously doing something wrong here. It could be some sort of "One Man Shop" stigma or something else. I've tried several different approaches from the friendly "Hey, let's work together" to the formal "There are win-win scenarios in a strategic synergy of our two paradigms". I'm actually a corporation, not just a DBA or similar, but I'm not sure that matters with regard to this situation. They don't even respond enough to find that out. My guess is I'm just getting dismissed out of hand for the same reasons as the bloggers I talked about earlier. I just need to build a larger name for myself (and the name 'Versatile Monkey' probably isn't helping, maybe I should switch to VrstleMn.ky and get some venture capital).

My Customers

My favorite part

BY FAR the best part of this whole experience has been the interactions I've had with my users. I made the decision to be as open and available to them as possible from the beginning. Every screen of my app has an 'Email Developer' menu item, and I had a forum going before I was even finished with the app. I also make it a point to tell my users what I'm working on and letting them know the real reasons things can't be done.

The results have been amazing. If you check out some of the blog posts' comments or some forum posts you can see just how awesome my users are. From actively extolling my limitless virtues to elaborating on why PodTrapper is better than competitors or worth the $10. Plus, I only had so many ideas for what to do with PodTrapper. Most of the UI niceties and even some of the complex features were a direct result of soliciting user feedback (I try to close out any support requests with "Let me know if you run into any other issues or have any features you'd like to see").

It's definitely work, but I wouldn't say a lot of it. I spend about an hour a day answering emails and forum posts, usually right after I get off of my day job. It's not something I'd be willing to sacrifice just to save some time. I'd actually like to be even more responsive than I am, people seem to really respond to it. I get a lot of email thanking me for getting back to them so quickly. Unfortunately I have the limitation in that I can't do work for PodTrapper (including emails) during my day job. A great trick I've learned, though, is to *always* answer your emails newest first. There's not really a difference between getting back to someone in 7 hours instead of 6, but there's a HUGE difference getting back to them 2 minutes later instead of an hour. Of course this only works if you get through all of your email in a sitting.

One thing I have noticed when dealing with customers is that not everyone is good with communication:

I think I misinterpretted his first email -- I thought he was complaining that I ripped off his idea, and he'd be "talking to me soon" with lawyers or something, heh. Good times. I actually don't mind getting these types of emails. My philosophy is that while yes, it would be great if no one had any issues, it's sometimes better for some users to have issues so that you can show how willing you are to fix it for them. Actually getting something fixed is apparently something that customers aren't prepared for and they seem to like it a lot. It probably ends up being a more positive experience for them overall than if the product had just worked in the first place. (Though not always, and I'm not about to start putting easily fixable bugs in there to experiment). It's more that each dissatisfaction issue should be seen as a way to make someone even happier than they would have been had they not had an issue. And even if I do get annoyed by some of the less thought out emails, ones like this more than make up for it:

Conclusion

Wow this article ended up being much longer than I had anticipated. I hope someone got some value out of it, and in exchange maybe it made some more people aware of PodTrapper. And you probably thought this whole thing was purely altruistic :). If there's anything I didn't cover that you're curious about drop a note in my forums, they don't even require registration.

Most of the Above in Outline Form:

• Why I did it
  • Listen to podcasts during commute
  • Need to carry blackberry for work
  • Didn't want to carry two devices
  • Saw potential on iPhone for sales, wanted to take advantage of BB App World when it became available
  • Sounded fun
  • Thought I could do it better than the next guy
• The platform
  • Java based, MIDP/CLDC or RIM specific
  • Decided to use full platform and go with RIM specific APIs
  • Choosing a version is problematic since not everyone has compatible versions
• Development
  • Look and Feel
    • Very limited widgets
    • The widgets are stark
    • Spent significant effort making it look good
    • Finding someone to hire for graphical help didn't work out
    • RIM has internal UI elements they don't publish
    • Results in inconsitent UIs across applications
  • Networking
    • Lots of networking options available
    • Very complicated to get working
    • Steep learning curve
  • Background Processing / Memory
    • Need to be constantly concious of memory use
    • Garbage collection isn't a magic bullet
    • Many BB devices have very limited memory
    • At least it's possible
• Pricing
  • Initially goal wasn't to make a huge sum of money
  • After beta at 9.99 wanted to up it to 12.99
  • Trying to keep it under the point where most people would question the value
  • Think it could be priced higher
  • I'd prefer people saw me as an incredible value than a tax on podcast listening
  • Thought about subscription models or paying for updates
  • Talked with some of my users about it (link to forum post)
  • Want to offer free version with ads (see third party integration)
  • Pay for features (flopped)
• DRM
  • Went with device-specific registration codes -- mistake
  • People switch phones a lot for various reasons
  • Haven't arrived at a viable solution that reconciles the competing goals
• Retailer experiences
  • Handango
    • Before going in to it Handango was the only service I'd heard of
    • I had (incorrectly) assumed they were the most popular since they were the only one I'd heard of
    • I also assumed that's how they justified their 50% cut (which actually turned out to be more like 60%)
    • Ended up dropping them eventually
  • Direct sales
    • Went through paypal, resulting charges are ~4%
    • A bit of work to set up
  • MobiHand
    • Much more reasonable pricing (80/20 split), except for all of the loopholes
    • Not many sales come from Mobi themselves, but through 'channel' sites, which themselves keep 20%
    • A lot of BB sites run their own channels and add a lot of value to their stores (mobile app stores, reviews, etc)
    • This probably should have been the first sales venue
  • App World
    • Definitely rushed to market
    • The marketing potential is huge
    • Needs some improvements
    • Great rates (80/20 always)
    • Costs money to participate -- $200 to start which covers 10 submissions -- waived for early adopters like me
    • Great support, even if it shouldn't be needed
    • Review process (end-user) needs improvements
    • Review can make or break an app
    • Needs a recommendation engine
    • Browsing needs to be improved drastically
    • Registration issues/teething issues
• Sales before marketing/betas
  • Word of mouth at first
  • Review on crackberry
  • Graphs
  • Realized I needed usage tracking
• Marketing
  • Pre-App World marketing was essential
  • Marketing is real work
  • You get back as much as you put in
  • After we started to see potential (after first crackberry post) we realized the potential
  • I'd rather spend time improving it than selling it
  • App world takes care of that, largely
  • Process we used
    • Each email was specific to the target, no mass mails
    • Started with what I thought was obvious (tech podcasts)
      • Didn't work out so well
      • Organic was the only way I got mentioned, marketing didn't matter
      • Didn't have the impact I thought it would
    • Next up, tech blogs
      • Worked out a little better, but not much
      • Crackberry is great
    • Next up, non-tech podcasts
      • Also didn't work too well
• Sales after marketing
  • App World is significant
  • Graphs and impacts
• Third party integration
  • It's really hard to get anyone to talk to you as a single developer
  • Need to be a startup that isn't actually making any money
  • "One man shop" stigma
  • Tried the approach of appearing to be a company
  • Integrations:
    • Audible DRM
    • Advertising network to provide an ad supported version
• Customers
  • Biggest reward
  • 'Email developer' menu item has worked well
  • Forums are crucial
  • Some people don't think about their comments (example email), but you can't let that affect the response
  • Very few negative comments
  • Public defense (link to examples)
  • Developers not communicating with their customers are missing out
  • Spend about an hour a day responding to emails and forum posts
  • Customers are the biggest source of new feature ideas
    • Try to always ask after solving a user's problem if there are any features they'd like to see