Five Years of FloodWatch

· 1702 words · 8 minute read

Since August 2010, I’ve had an app in the iOS App Store named FloodWatch.  It’s an app that can be used to monitor rivers, creeks, and other bodies of water all over the United States and its territories.  Its data is sourced from the US Geological Survey.

Specifically, all ~8,000 river gauges in the United States with real-time data capabilities can be accessed from within the app.  The app hits USGS web services directly to retrieve its data.

USGS gauges can report on a variety of data, such as current river height, amount of precipitation that has fallen, and current water flow amount (“discharge”), among other values.  FloodWatch surfaces height, precipitation, and discharge values.  If the National Weather Service has defined flood stages for a particular gauge, those are presented within the app, too.

Who’s my target market?  People living within the United States who are residing or have property near rivers, streams and creeks that might be prone to flooding.  These customers have either experienced a flood that affected their property in the past, or they’re aware of the possibility and want to keep an eye on their nearby rivers as a result.

First, we’ll talk about some history and motivation behind FloodWatch.  Next, we’ll talk about how it’s performed revenue-wise and against its goals.  This is the story of the past five years.

History 🔗

The idea for it was born out of our home being flooded in September 2009.  I really never paid any attention to the nearby creek, but once it ended up running through our living room, I figured that it deserved a bit more attention.  So, what’s the old adage?  “Build an app that you’ll find useful, and others will find it useful, too.”  That’s exactly what I did.

First, let’s talk about a little history.  I’ve been a web developer since 2000, focused primary around PHP and open source technologies.  In 2009, I started feeling like I wanted to branch out a bit by gaining exposure to other languages and platforms.  There was more to life than web development.  iOS was a growing platform at the time, and I had been using a Mac for about four years.  Objective-C and the iOS platform were so wildly different than PHP and web development.  I wanted to challenge myself, and do some development that helped me develop new skills in other areas of technology.

So, I picked up a few books and started to learn.  I spent February - August of 2010 building FloodWatch in the evenings and on weekends.  I figured if I could pick up some new skills, and maybe make a little bit of money, then it’s a win-win.

In the early days, I’d strive for “just make it work,” with little concern for if I was doing things The Right Way(tm).  This was back in the days of retain/release, and I can’t say that I truly understood the ownership aspects of memory management, so I was just retaining things all over the place.  :)  I cleaned up all that mess in later releases, shortly after ARC was introduced.

It’s worth remembering that I’m a developer.  I can implement things, but I’m not a designer.  So, the app is generally using stock iOS views and controls.  It’s clearly designed by a developer!

FloodWatch went live in the iOS App Store on August 17, 2010.

I stood up a super basic, ugly web site for it shortly after launch.  It’s in dire need of some updating.

Motivations and goals 🔗

First, I wanted to use this app to grow my skills with Objective-C and the iOS platform.  I’ve maintained the app over the past five years; it’s had a small part in helping me keep my iOS skills up.  For example, I’ll always update it around major iOS releases by adopting new frameworks when it makes sense.

Secondarily, I wanted people who also lived near rivers and creeks that might have flooding concerns to find it, and hopefully find that it was a useful tool.  That goal was definitely met, as you’ll see below.

FloodWatch has always been free.  It was ad-supported, with Apple iAds running within the app.  I never expected to make a ton of money off of it, and I haven’t.  I’ve added in-app purchases over time to further monetize it, though.

Marketing 🔗

I’ve done very little marketing over the years.  I’ve run a few Google AdWords, Facebook, and Twitter ad campaigns around major flood events, but that’s it.  If there’s flooding happening in the US, I’ll tweet about it from @d5gtech.

App Store search is the largest driver of downloads, at least as far as I can tell.  There aren’t many relevant results for keywords like “flood”, “floods”, “flooding” and the like.

It is mentioned on the US Geological Water Web Services Showcase.  It was featured in a book, Death, Decomposition, and Detector Dogs: From Science to Scene as a useful tool for police dogs when searching rivers in search and rescue operations.  Crazy, right?!

I’ve received emails from members of the US Geological Survey, National Weather Service, Red Cross, tugboat captains, firemen, and recreational fishermen, just to name a few.  The app has been used by many different types of people for many different reasons.  That said, it’s my belief that the vast majority of users have real reasons to monitor their local rivers and creeks.

Numbers! 🔗

FloodWatch has been used by someone in every state within the United States.  Here are some high-level figures:

  • Total installations, all-time: 28,000

  • **Average number of unique users per month: **2,270

  • Total revenue: ~$2,600 (after Apple’s cut!)

    • In-app purchases: $720

      • **Ad removal units sold: **320

      • **Tip jar level 1, units sold: **24

      • Tip jar level 2, units sold: 8

      • **Tip jar level 3, units sold: **2

      • **Tip jar level 4, units sold: **2

    • iAd proceeds: ~$1,880

  • Approximate number of support / feedback emails received: 250

In general, my purchase conversion rates are terrible.  I’m clearly not doing this for the money.  Instead, it’s a pet project, and if you include my time spent in development, it’s not profitable at all.  I should’ve killed this app years ago, but people find it useful, so I keep taking care of it.

My only annual costs to support the app are my Apple Developer Program membership ($99), my LLC renewal ($50), and AppFigures ($108/year).  So, it’s “profitable” if you don’t include my time.  On average, my Apple deposits are $30-$60/month.  In good months, it’s climbed to $100-$120/month.

Diversifying revenue 🔗

My user base grew over time, especially during and following major flood events.  People have found the app to be useful, so I’ve tried to monetize it differently over time.  Along the way, I have added the following sources of revenue and exposure:

  • iAds: [with initial launch]

  • iPad-optimized UI: January 2014 (universal app)

  • IAP to remove ads: January 2014

  • IAP for four “tip jar” levels: April 2015

The in-app purchase additions made a big impact to revenue, but iAds have always been the largest share of revenue annually.  It’s an app that people use when flooding is on their minds, which obviously has a strong correlation with mother nature.  Flood events can happen anytime, of course!

Now there’s news that Apple will be discontinuing the iAd network.  If that ends up being the case where ads stop running after June 30, 2016, then, needless to say, I’m going to need to change my monetization strategy!

So, why keep it up? 🔗

You might be asking yourself “Bah, a lousy $2,800 or so…why bother?”  Great question.

Why do I keep maintaining the app?  Because its goal of helping people has been clearly accomplished.  Sales spike around major flood events in the United States, which tells me people are finding it useful.  They may not use it every day, and only a tiny percentage of them pay for an in-app purchase, but…that’s not the point.  The point was to build a useful tool.

Here’s a timeline of monthly app downloads directly from iTunes Connect, with flood events annotated.  Click to enlarge the image below:

FloodWatch graph

Here’s the breakdown of total number of sessions by state over time in the United States:

FloodWatch map

What can I say?  I’m huge in Texas and Louisiana.  :)

So, that goal of other people find it as a useful tool?  Mission accomplished.

What’s next? 🔗

In terms of future development for FloodWatch, I have a few things in mind for 2016.  Among them:

  • Preparing for the iAd network retirement if ads will indeed stop running after June 30, 2016

  • Add social sharing of river status (Facebook, Twitter, etc.)

  • Redesign the UI from the ground up – move beyond stock views and controls!  This might give it a better chance of being featured by Apple, too.

  • Add Push Notifications when a river’s flood status changes (possibly a monthly subscription model)

Obviously this iAd situation would have me completely reconsider the app’s strategy.  Frankly, it might be worth killing.  Otherwise, I would have to consider options like:

  • Take it to the paid upfront model; $1.99?

  • Remain free, but move to a monthly subscription model

  • Remain free, and rely on the “tip jar” other other patronage model

Someday, I’d like to spend a greater portion of my time focusing on iOS and Mac development.  FloodWatch has enabled me to develop and further my skills on iOS and Mac platforms, so it’s been a very rewarding effort in terms of experience.

The reward 🔗

All of the revenue considerations aside, it’s great to have played a small role in helping potentially thousands of people all over the US, some of whom may have had their homes and property flooded just like I did.  As you might imagine, going through a natural disaster that affects your home can be a taxing, traumatic experience.  I like to think that my app has been truly useful for at least a few hundred people across the US.

When you consider that, develop and maintaining FloodWatch has been worth it.  It may not be the most profitable venture ever, but it sure is a noble one.

I like that old rule of thumb from above: “Build an app that you’ll find useful, and others will find it useful, too.”  It’s true!