Keeping your wits as an indie app developer

Carlos Ribas
iOS App Development
6 min readMay 6, 2015

--

Taming scary day-to-day sales spikes.

A few months ago, I blogged about how I got started developing apps and the journey of going from hobby project to a real side-income. Vic Hudson and I subsequently explored that topic in-depth on App Story Podcast.

Over the years as my app sales income has grown, the time spent at my day job has increasingly felt like a missed opportunity. So last month, I (finally) decided to take the plunge and quit my day job to focus on building and selling my own apps full-time. The transition over the past few weeks has been interesting.

There’s no doubt that I can support my app business much better now that I’m entirely focused on it. I have a lot more time to work on cool features, fix bugs, or even build entirely new apps. I have the freedom to work on what I want, when I want, for as long as I want. But, along with those freedoms come some real trade-offs. Probably chief among them for me is the notion of financial security.

What happens if it all ends tomorrow?

From this side of the fence, working for someone else feels like a much easier arrangement. I show up each day, put in a good effort, and always get paid the same. As long as I can keep doing that, I have stable, dependable income to pay my bills and support my family with. Things can feel pretty different as an indie app developer as no two days selling software directly to users is the same.

Before going full-time indie, I spent some time defining what success meant to me and finding better metrics that provide a more accurate perspective on my business. There are two major indicators I’m looking for when considering various metrics:

  1. Income. Am I succeeding as an indie app developer? For me, this means I’m not giving up too much income vs. having a normal day job. Ideally I’m doing better.
  2. Growth. Am I doing the right things in terms of features, support, marketing, and promotion? When I’m doing those things well, revenue is not shrinking. Ideally it should be growing.

I think for most of us developers, the most accessible metric is daily app sales. Here’s what that looks like for my business:

Daily Revenue from Apps

daily fluctuations of almost 70% make it hard to keep calm and code.

This wild spiky chart does not do a great job providing perspective. Some days it looks like I’m knocking it out of the park, other days it looks like I should be focusing on my LinkedIn profile. Really this gives me zero idea of how things are going in terms of income or growth. It can be really stressful.

Seeing the bigger picture

One major component of those day-to-day variations is that HoursTracker is mostly useful when people are at work. On weekends there are less people using it and deciding to upgrade or tell their co-workers about it. Maybe developers who build games or other kinds of apps don’t have sales patterns like these. But, for my business app this pattern suggests I would be better off looking at weekly reports instead of daily.

Weekly Revenue

Same period as Daily. Weekly fluctuations of 11% are much more soothing.

Looking at weekly revenue eliminates weekend dips and reveals that the weekdays average out pretty consistently. But, weekly reports only update once per week. Who wants new data only on Sundays? Feeling like you’re in the dark is never good. And, weekly reports don’t reliably provide an indicator of growth (more on this later).

Since the most significant advantage of weekly reports vs. daily reports is that they include one occurrence of each day of the week, a Trailing Revenue graph should achieve a similar smoothing, but updated on a daily basis.

Trailing Seven Days Revenue (T7D)

Same period as Weekly. 20% fluctuation is a good compromise.

Each point on this graph is that day’s revenue plus the revenue from the six days before it. For me, this is a much better metric to glance at each day. It provides fresh data that is still scrubbed of most of the expected day-to-day volatility.

Seeing past Seasonality

The T7D graphs go a long way to calming the weekly peaks and valleys, but they don’t help with other types of seasonality. For example, every year my revenue drops off in the lead-up to Christmas, then picks up after New Year’s Day. This coincides with times when most people take time off from work.

Christmas through New Years T7D Revenue

Even smoothed using trailing seven days, this is a 54% range.

Since the valley around Christmas Day and the peak after New Year’s Day is expected every year, the Trailing Seven Days chart isn’t very meaningful during these couple of weeks.

Some other examples of seasonal influences are:

  1. Good Friday (less sales)
  2. Thanksgiving (less sales)
  3. September/October Apple product launches (more sales!)
  4. Spring Break (less sales)

Data near these events really doesn’t mean anything in isolation. For example, really strong September revenue doesn’t mean I’m doing a better job or that my recent promo efforts are working. It probably just means Apple is crushing it with their newest iPhone launch.

To see through this seasonality, I like to use Trailing Year Revenue graphs. This is just a bigger version of the T7D graphs, where each point on the graph represents the entire preceding year’s revenue. Sometimes this is drawn on a quarterly basis, but I usually do it with weekly or daily data. So if it is based on weekly data, each point is that week’s revenue plus the 51 weeks before it.

Here’s the T1Y graph for the same time period in that preceding chart:

Christmas through New Years T1Y Revenue

The trailing year graph shows a small amount of growth over that holiday period and reveals that the deep valley around Christmas and the spike just after New Year’s are likely entirely seasonal. Because each point on the graph includes one occurance of each day of the year, seasonal events don’t muddy up the big picture.

Having a set of metrics like these really helps with the stress of being an indie developer. With Daily, Weekly, and Monthly sales reports, I have a pretty good idea of how I’m doing in the short-term, and trailing revenue charts provide broader perspective at a glance. Combined, these things help me focus on making my products better.

A major strategic mistake and subsequent recovery visualized on a T1Y Revenue chart

I built a web-based dashboard that draws these charts using data from the AppFigures API, some simple code to calculate the various metrics, and the JavaScript charting library Flot.

Here’s what is currently on my Dashboard web page:

  • Daily Sales, last 14 days
  • Today’s Real-Time Top Grossing Ranks for each app (kind of useless lately!)
  • T7D Revenue Overall and by channel (Google Play, App Store, Cloud Subscriptions, …)
  • Daily Revenue % by channel (“product mix”)
  • T1Y Revenue Overall and for major segments

If I find myself starting to worry about any given metric, I add it to that page. Then, I can pull this dashboard up any time and at a glance I can see how things are going.

Then I can get back to work. ☺

UPDATE: As requested, I posted a Gist with PHP/HTML/JS source code for a dashboard web page. So if you’re a developer (and AppFigures customer) wanting to build your own Dashboard, this might help get you started: https://gist.github.com/malatx/b7f33289d37442c918a5

--

--