Matt Netkow
About Blog Projects Contact
That Conference 2014 Recap

Wow! Another fantastic That Conference experience.  This was my third time in a row going and I couldn’t have been happier with how it turned out.  Some highlights:

  • My first public talk!  I’ve been wanting to speak for years but the timing was always off or I procrastinated.  I spoke to a packed room about developing Hybrid Mobile apps, leveraging my experience building Fitwatchr.  The audience was very engaged, asking lots of questions both during and after my presentation.  I was nervous at first but had practiced extensively (about 10 times) so once I got going, I was in the zone and spoke fluidly.  I really enjoyed the experience and look forward to giving the talk again.  I plan to record a video of it, as well.  The biggest lesson learned is that it takes a lot more time then you’d think to put together a well made, focused, hour long talk.  I thought it would be hard to come up with 1 hour’s worth of material; quite the opposite, in fact! I had to cut out a bunch of content.  Overall, it took me about 30 hours of effort to plan, research, create, tweak, and practice my talk. I have a new found respect for speakers now!image
  • Kids activities: Each year, the number of full families that attend is noticeably increasing.  This is fantastic not for the water park aspect, but for the exposure to programming/development.  We have a severe lack of engineering/science graduates in the U.S., so getting children interested in science by bringing them along to Mom or Dad’s conference is a great way to remedy this.  This year, kids actually gave talks (and I thought it was cool that I gave one! ha!) and also had more adult-lead sessions to attend.  If I have kids someday, I will definitely be exposing them to programming.

  • The talks: Quite heavily web, mobile, and JavaScript focused this year.  The best ones I attended were “Full Stack Web Performance” by Nik Molnar, “Black Art of Cryptography” by Robert Boedigheimer, and “Real World Data & Tactics for Touchscreen Design” by Steven Hoober.  The keynotes were also the best they’ve been in all 3 years; very inspiring!
  • The experience: Between the opportunities this conference offers, to the community of amazing people, That Conference is such a joy to attend.  Every year I’ve been able to do something that has helped me grow professionally: in 2012 I won a hackathon, in 2013 I built software for charity, and this year I presented a talk.  Naturally, I’m looking forward to 2015!
Adobe App Design Course Presentation

A few nights ago, I had the pleasure of presenting to an Adobe Education Exchange class on "App Design", specifically using Adobe tools like Brackets and PhoneGap Build.  It’s a neat concept - a 2 week course, taught 100% remotely over Adobe Connect at night (7pm CST in this case).  I was happy to spread the word about PhoneGap Build!  

I presented for 10 minutes on how I used tools like PhoneGap Build to create Fitwatchr and gave some advice for beginners.  Afterwards there was a 5 minute Q&A session.  This was a lot of fun! There were tons of questions regarding how Fitwatchr works and even a bunch on the mobile industry, the state of wearable technology, and more.

You can see my slides on GitHub here.  If you attended the class and have any follow-up questions, please don’t hesitate to send me an email!

Why I Charge for my Mobile App, Fitwatchr

The prevailing strategies to monetize mobile applications in 2014 involve the inclusion of ads, in-app payments, or charging a flat fee - typically $0.99.  When I was deciding how to charge for Fitwatchr, I read many articles on various approaches.  I didn’t expect to reach the volume of users needed to make decent money with ads, which is typically thousands with high engagement, so that option was out.  In-app payments seemed inappropriate as well, since I didn’t like the idea of presenting the most useful features behind paywalls.  Therefore, I decided on charging a flat $2.99 for the app, as I loathe the bottom barrel $0.99 price, which I will discuss later.  I’ve been charging for Fitwatchr for about 9 months now to some success - we’ll hit 10,000 users by mid summer 2014.  Without the obvious reason of a monetary incentive, I’ve also encountered some real benefits to charging for an app:

1) It gives people “skin in the game”

They’ve made a financial investment, albeit small, so they tend to care more about the long term experience of the app. They are likely to use it multiple times and give feedback.  To be honest, in the very beginning, most of the feedback I received was negative.  However, connecting with users is a rewarding and humbling experience and I have learned quite a lot through that process.  In addition to enhancing customer service skills, you can leverage the positive and negative feedback to improve the app’s quality and overall experience.

2) To fight against the devaluation of consumer software

Software app costs vary widely between the business and consumer worlds.  B2B engagements are quite healthy, with developers being billed for hundreds of dollars an hour and unless you are independent, you see a fraction of that.  This generates many multitudes of value for the receiving business, making it well worth it.  On the other hand, however, App Store prices have been a race to the bottom ever since they launched years ago.  I fear that this devalues software in the eyes of the average consumer; charging more than $0.99 is now viewed as too expensive, nevermind the Starbucks latte that costs easily twice as much!  Even my fellow software developers were shocked to hear that I am charging $2.99.  My app revolves around exercise and weight loss and has the potential to be relevant for years to come.  If software provides long-term, consistent value, the cost should reflect it - regardless of industry or business type.

3) Market Validation

Charging for the app also provides a critical aspect of market validation - if people are willing to pay, your idea is on the right path.  Validation is lessened with a free app, due to how casual the installation process is: users download it, open it, and can remove it quickly if desired. However, a monetary cost acts as more of an upfront blocker; consumers may review the app in depth before committing.  With a paid app, the market directs the product.  

Overall, there isn’t one definitive path to take when deciding to create free vs. paid mobile apps.  Every app should be reviewed on an individual basis by the developer.  What are your arguments for free vs. paid? Let me know in the comments below.