Matt Netkow
Projects Speaking About/Contact
Fitwatchr, 1 year later: $26,000 profit and 14,000 users

One year ago, David Lapekas and I released Fitwatchr, a mobile app that converts Fitbit activity into Weight Watchers points.  Following in the footsteps of other indie developers and entrepreneurs that I look up to such as Patrick McKenzie, Nathan Barry, and Pat Flynn, I’m very excited to share our experiences openly.

Humble Beginnings

The idea for Fitwatchr began after I bought a Fitbit device a few months after joining Weight Watchers.  I thought it would be useful if I could convert my Fitbit exercise into Weight Watchers activity points.  Activity trackers were just starting to take off, and so the more I thought about it, the better the idea sounded.  I decided from the beginning to create the app for multiple platforms and decided on a PhoneGap approach.  A few months of work during nights and weekends later (my front end skills were iffy at best, so this added time), I had a prototype built.  I partnered with Dave to handle all art and marketing efforts.

We launched Fitwatchr in August 2013 on the Google Play store for 99 cents, to much critical acclaim and massive sales.  Just kidding -  there were just a handful of sales here and there.  Having read a lot about app strategies, I started slowly by building an MVP in order to validate the idea and get some initial customers. This worked very well - I charged for the app, people bought it, and I got great initial feedback that was crucial for the eventual success of the app.  For the next few months, we polished the app, adding features suggested by users and making sure that the stated goal of the app was rock solid (converting Fitbit activity into points). We didn’t focus very much on marketing; mostly, we worked on improving the app while leveraging social media and Weight Watchers and Fitbit forum boards to drum up interest.

The Turning Point and Sales Breakdowns

Six months after the iOS release (October 2013), sales began to pick up, completely out of nowhere.  We had decided on a $2.99 price point after comparing ourselves to other health-related apps and running a bunch of pricing experiments. Towards the end of February 2014, we got 800 sales! I was ecstatic.  It didn’t stop there; in fact, March exploded!  The two factors that contributed to this where great SEO coming from the Fitwatchr announcement post I wrote as well as finally showing up in search results for “fitbit” on the App Store.  The key to this really was that at the time, there were no other Fitbit iPad apps - just ours!  Over time, other Fitbit apps appeared and lots of users were confused on the app’s purpose, leading to negative reviews and a steady decline in sales: 


We fought the bad reviews as best we could: by improving the app’s usability and adding a customer support website.  iOS accounts for nine tenths of our revenue.

In comparison, Android on the Google Play store has had more modest yet stable growth (currently 1,200 lifetime downloads):


Android on the Amazon App Store currently sits at 359 downloads for the year.  Not bad, considering there is minimal effort to upload the exact same app package that Google Play gets.  It’s an alternative Android marketplace though, so I’m sure it will never quite catch up to Google Play.  Since I built Fitwatchr to make cross platform feasibility easy, we eventually put out a Windows Phone version.  It’s had only 12 sales so far.  This is not surprising as WP has the smallest portion of the market.  As for the disparity of sales between iOS and Android, I believe that the cause is twofold: the idea that Android users do not buy apps like iOS users do and our lack of focus on marketing or ads.  From what we can tell, word-of-mouth and good reviews are driving steady sales on Android.

Some Thoughts on Profit vs. Effort

It’s possible to see the financials here and get an idea that creating a successful app is easy - frankly, it’s not.  As I mentioned above, it started as a passion project on nights and weekends before turning into a serious side gig.  While unfortunately we didn’t track hours worked in the early days, I can say that when you compare hours put into the app to the money we earned, we most likely are barely making minimum wage.  I’m certainly not complaining, as making any sort of profit is incredible given our world of free and “race to the bottom” app pricing.  Also not to discourage anyone from starting out, as I do think app development is absolutely worth it!  It’s amazing though the extra stuff you need in order to market and support your app:

  • A beautiful website
  • Great looking graphics, icons
  • Customer Support (contact email at the very least!)
  • Ads
  • Social Media

Next Steps

It’s been a great ride working on Fitwatchr so far.  We’ve learned a ton, helped people lose weight, made a bit of money, and are poised to do even better in 2015. In fact, Upwatchr, our brand new app for Jawbone devices, will be launched the end of the year!  In addition to new features, we’re continuing to invest in marketing, ads, and social media as well as bring more apps to market!

One thing is for sure: if we can do it once, we can do it again.

The Developer’s Core Concepts 2014

Recently, I’ve been mentoring junior developers, offshore resources, and even answering questions about coding with friends that are just getting started.  It got me thinking - what concepts cover everything one needs to be a well rounded developer? 

This assumes at least some level of experience with programming/computer science and is aimed at those just starting out in industry after earning a CS degree or coming back to development after a period of absence.
Simple Programs
While it’s tempting to start off with web projects, I feel that JavaScript and working with the challenging DOM introduce the wrong type of complexity right from the start.  Beginning with an object oriented language (I’m biased towards Java or C#) helps keep a tight focus.
  • Version Control:  It doesn’t matter which one, as long as it’s used in the first place.
  • Logging: Use a 3rd party library here; no need to reinvent the wheel. The idea is not how to log, but rather to learn which information is important to log, so that debugging in the future is easier.
  • Storage: This can include the file system and eventually, databases.
  • Connecting to external services: Many use cases require extracting data from 3rd parties and manipulating it.  Picking either a REST or SOAP API is a good start.
  • Unit Testing: Even in 2014 this is ignored, but shouldn’t be.  Code coverage should be as close to 100% as possible.
  • Inversion of Control (IOC) and dependency injection: These are a bit advanced, but should be covered as soon as the developer is familiar with the other core concepts.
From browser quirks to understanding the DOM and the rapid pace at which web technology changes, programming for the web is a very challenging endeavor.  It’s also the most rewarding, though.  The capabilities of the web stack open up unlimited possibilities for employment and innovation.
  • The Basics (HTML, CSS, JavaScript): These fundamental languages will always be used.  Furthermore, they are now being used in other platforms besides the browser, including server-side (Node.js), cars, smart watches (Pebble), and mobile apps (PhoneGap), making them highly valuable, reusable skills to have.
  • HTTP: This includes understanding how the client-server model works and all the protocols that go with it.  You can’t truly become an expert on building websites, the DOM, and calling APIs without it.
  • One design pattern: The current most popular one is Model View Controller (MVC).  Model View View Model (MVVM) is great too.
Recommended Books
It’s not hard to find books on software development, methodologies, and best practices.  Knowing which ones are worth the time though is.  Here are my favorites that have contributed significantly to my career:
  • The Pragmatic Programmer: My all-time favorite that I tend to read about once per year. Each chapter focuses on one specific software practice, with a pop-out checklist at the back of the book.
  • The Passionate Programmer: This is focused more on developer soft skills.  The greatest lesson in here is that in order to truly grow and help your company, you must learn at least a bit about the business side of things.  Tons of gems in this one.
  • Code Complete: Over 20 years old but a classic. Focuses on development best practices that, while examples are in C/C++, are truly language agnostic.
  • The Art of Unit Testing: A very succinct look at unit testing: what it is, why you should use it, and full examples. Also included is dependency injection, which I am a huge fan of.
  • Head First Design Patterns: Part of the “Head First” programming series, this covers design patterns in an easy to follow manner with examples in Java.

Am I missing anything? Please let me know in the comments.

Open Source PhoneGap Build App Template Now Available
It started innocently enough: I built a proof-of-concept PhoneGap app that could connect to a Fitbit user’s account using OAuth.  Satisfied with the results, I kept going, adding feature after feature until I had a completed app.  Unfortunately, despite the relatively simple codebase that PhoneGap apps consist of, I still ended up with a monster on my hands!  It was time to refactor.  Through this process, I completely rethought how to separate concerns (UI, API, storage, plugins) in a PhoneGap app.  Here’s the complete breakdown - I’ve open sourced the template too!
First, create a new root directory for the app (or just pull down my starter template, of course!).  In this example we’ll use “app” as the App name.  Within here will be everything related to the app, including code, tests, and app platform certificates:  
\www: All assets of the app, including code, image icons/splash screens, and PhoneGap Build configuration files.  You don’t have to name it “www” or separate the app code from tests/certificates/other metadata, but if you do, there are three benefits:
  • You can zip up the folder and upload it to PhoneGap Build without unnecessary bloat being added to the compiled app.
  • Should you decide to move away from the PG Build service and wish to compile the app manually using a specific platform SDK, you’re all set - PhoneGap/Cordova files are always placed into a “www” folder.
  • It will automatically be ready for use with the PhoneGap Developer App, a great tool that allows you to debug your app locally on a real device.  Each time you save a file from within this folder, the files get reloaded on the test device.  This is a lot faster than uploading to PhoneGap Build, waiting for the app to build, then reloading it!
.cordova: PhoneGap App configuration files.  This can be ignored if you don’t intend to use the PhoneGap Developer App. 
\tests: All JavaScript unit tests.
\certs: All the app platform keystores and certificates that are used to digitally sign your app.
\www folder contents
index.html:  This is the single page app itself.  It should contain only HTML and CSS, and link to separate JavaScript files.  You may have a bit of initialization code, though.  For example, using KendoUI Mobile:
var app = new, { transition: “slide” });  
// other initialization steps, such as reloading previous app state from localStorage, etc.  
config.xml: The one file that PhoneGap Build uses for configuration when creating your app.  Included in this are the platforms to build for, deployment preferences, icon/splash screen image references, permissions required (Internet access, location awareness, etc.), and plugins used.
icon.png: You can create many icons for each device resolution, but there must always be an icon in the root of the app code directory at 512x512 pixels.
splash.png: Similar to icon.png, if you use splash screens in your app a root image must reside in the main directory.
\icons folder: This contains all icon sets, neatly arranged into separate folders for each platform (\android, \ios, and on).
\splash folder: Exactly like the icons folder, but for splash screens.
\img folder: This contains all static images used in the app, from loading gifs to other custom pics.
\styles folder: This contains all CSS files.
\scripts folder: This contains all JavaScript code libraries.  Within here, I have the following:
  • \kendo folder: While technically containing both CSS and JavaScript, this is the open source Kendo UI Mobile framework used for creating a single page application.
  • controller.js: The main app controller that ties all app dependencies together, including UI interaction, user management, and data storage (localStorage, databases).
  • phonegapAppPlugins.js: All PhoneGap plugin helper code. This IIFE encapsulates plugin API’s here rather than incorporating them directly so that you can test/run your app in the browser (where they are not available of course).  I built this with extendability in mind, making it easy to add other plugins as necessary.  Check it out on GitHub.
  • dataRepository.js: This encompasses any data source.  In my case, it was the Fitbit API calls.  Using dependency injection in controller.js, I can now use any 3rd party API that I wish or test locally by not calling any external service.
  • viewModel.js: If you happen to use a MVVM style when building an app, it’s helpful to split the view model code into its own file.
  • Other JavaScript files: Any other code libraries.
Finalized structure: (generated using ‘tree /F’ cmd)
This is how I structure my PhoneGap Build apps.  If you have any ideas on how to enhance this, please let me know in the comments or submit a pull request on GitHub.