12 Feb 2017
I recently released a version of my Count the Days Left app which included ads for the first time.
I thought long and hard before doing this, so I thought it might be interesting to document how I worked through this decision, as it’s pretty typical
of the trade-offs independent software developers have to make.
How I make money
I’ve been a commercial software developer for nearly 30 years now (wow!), including over 10 years working at Microsoft (MSN/Bing/Skype).
Right now, I split my time between:
- Contracting out my skills to businesses for fixed-term projects
- Building mobile apps and websites for businesses
- Developing my own iOS and Android apps for both pleasure and profit
In 2017 I’m trying to diversify my business more, so the 3 areas above contribute more equally to the bottom line.
Currently, by far the biggest part of my income is working on contracts for other people,
and I’m trying to generate more independent streams of income so I can be more in control of both my time and where I work.
Why I built Count The Days Left
I built the app for a few reasons, but mainly:
- I wanted to showcase my skills to generate potential business
- I wanted this app for myself, and most of the alternatives in the App Store were either ugly or not quite what I wanted
For the first point, I’ve blogged extensively about how I’ve built the app,
as well as open sourcing the code on GitHub so potential customers can see my work.
The app has been pretty successful in meeting these aims, and has definitely helped in generating business (although it’s hard to measure the actual monetary value of this).
As you’d expect from a simple and niche app, it doesn’t have masses of users - daily users are definitely in the hundreds rather than the thousands.
In fact, some of the features (showing the days left as an icon badge, the Today widget, plus the Watch complication and app) are designed so the users don’t actually need to open the app every day, but I’m pretty proud of how it’s turned out.
Monitising the app
For any iOS app, there are three main ways of making money from an app:
- Charging to buy the app
- Adding an in-app purchase or subscription, probably to unlock additional functionality in an otherwise free app
- Adding ads
Now, unfortunately I suspect there is very little chance I’d sell many copies if I decided to charge for the app.
There are so many free competitors to this particular app, and even if my app is better than them - and obvioiusly I think it is :) - it’s very hard to
see how many customers would agree.
People are now so used to getting high-quality free software, generally from venture capital backed companies who are happy to lose lots of money
to capture large audiences in the hope of monitising that audience later. That makes it a very hard sell to convince people even to spend $0.99 on an app that
might provide them with lots of value.
Personally I’m happy to pay for good software, especially from independent software developers who are doing great work.
However I completely understand why most people
don’t think in that way, and as I can’t see the situation ever changing, for most consumer apps I can’t see there’s much point in even charging a very small amount.
Now this particular app only really does one thing (although hopefully it does it well!), so I can’t see any sensible way of adding “pro features”
to be unlocked by an in-app purchase.
I guess I could try a patronage/shareware model, and ask for money to support the app?
I’m not sure that would actually generate any money without some sort of persistent nagging which I don’t think I’d be happy with.
This probably gets to the nub of my problem with all of this discussion. I’m not sure if it’s a British thing, but the conflict between needing to get paid and
somehow seeming to be only doing it work the money is complicated.
I do want people appreciate and enjoy the app, and somehow this should be separate from the dirty business of getting paid.
So this just leaves adding ads.
I didn’t want the app’s main screen to show ads at any time. I think its’ main selling point is it’s a tasteful and good-looking app
(especially compared to some of my competitors), and slapping an ad there would completely negate that.
Therefore only other place left to put the ads is on the settings page, where you change the title, start and end dates of what you’re counting down to.
I’m reasonably happy with this compromise, although from a pure money-making point of view this page is not viewed very often, as the users only go thereevery time they start a new countdown.
I’m using Google to provide the ads via AdMob, and have customised them to be text-only and in a color that matches the rest of the app. At least in that way they are not too
jarring, and fit in as well as I can make them.
As you can see from this example, the way the ad looks is OK (even though the content is frankly a bit shit)
Is it worth it?
In the first week, I’ve made a few pennies - slight more than I expected, which was very little be honest!
However, I’m generally happy I’ve done this. I think it’s important all software developers get paid fairly for their work,
so turning the tide against the idea all software should be free - even the the smallest way - is OK.
Obviously giving Google even more data is not “free” for my customers, as they are now paying for the app with their information.
I’m not 100% happy doing that, but as I’ve hopefully explained here, it’s a complicated trade-off.
Feel free to contact me via Twitter at @yeltzland if you have any thoughts on any of this.
I’ve now added an option to pay to remove the ads - read about it here
05 Feb 2017
As I’ve written about before (read here and here
for some background), I’ve got a crazy-complicated system to manage my shopping list, involving my Amazon Echo, Todoist, IFTTT and Slack.
The original system was working OK, but it had several non-optimal parts including:
- Getting a notification every time I was near the supermarket, whether there was anything on my shopping list or not
- Even if there is anything on the list, I get the same alert each time
- Ideally I’d like to see what is on the list in the notification, rather than just a link open Todoist. That would mean I can see on my Apple Watch
what I need to buy without having to get my phone out.
I thought I’d draw the new, improved setup on my whiteboard to make it a little clearer to explain …
When I was building the original system, I didn’t know about IFTTT Maker Channel, which can:
Integrate other services on IFTTT with your DIY projects.
You can create Applets that work with any devices or apps that can make or receive a web request (aka webhooks).
This is fantastic, as you can really build some complex systems that hook into your own logic. So with a little more work I can now build exactly the setup I want.
New Service Logic
The logic for Shopping List v2.0 is as follows:
- Setup two location-based IFTTT applets that trigger when I am near the two Hexham supermarkets (as before)
- The “that” part of the applets now simply make an API call to my web server (passing a secret authentication token for security)
- The web service, on receipt of an authenticated call, will:
- Call the Todoist API to see if there are any items on my shopping list
- If the list is non-empty, and has changed since the last call to the service, make a HTTP call to a third IFTTT applet (passing the shopping list details as a parameter)
- The third IFTTT applet simply coordinates the incoming parameters into a Slack message sent to me
You can see the results from yesterday’s trip here:
The first alert was when I got to Waitrose, and after I’d crossed off 3 items from the list in Tododist, when I got to Tescos it then reminded me about the final item.
I’m pretty happy with this now. It really is great to use Alexa as a way of managing our shopping list, and I don’t use any other way of doing it any more than by voice.
Yes, it is a pretty nobby list of things to fetch (I was going to Waitrose after all).
And no, I never did get the Sausage Casserole mix. It appears Hexham is all out right now.
27 Jan 2017
Version 2.3 of Count The Days Left has now hit the App Store for your viewing pleasure.
I finally got around to upgrading the code to Swift 3. The Xcode migration code did a reasonable job with the syntax changes, but missed a few things around interface changes - especially in the WatchOS code - that
I had to fix manually.
I also fixed a very minor logic error in the date calculation in the settings page. Quite amazing it had been sitting there in plain sight for a long time without me noticing it.
Not much more to do in the app right now, but maybe WWDC in the summer will bring some exciting new areas in which to play in?
12 Jan 2017
In the near future, Writing on Tablets is obviously be massive success, when the whole world discovers pearls of wisdom like these.
However right now, I get many more readers on Medium - although still not many! - so I’m currently duplicating posts from the website to Medium.
I want to automate this, and in theory I should be able to do this through IFTTT by hooking up the site’s RSS feed and my Medium account. However, for whatever reason this has never worked for me.
On a PC, it’s pretty easy to copy and paste the website page content into Medium, but as ever this isn’t quite so easy on an iPad.
However, what we do have is the Workflow App to help, and I’ve built a workflow to do just that.
The workflow takes a selection from Safari as input (via the Share extension), and uses the Medium API to first get your user ID, and then post up the selected content as Markdown.
I also added some code to automatically append an attribution for the original page at the end.
The code needs an Medium Integration Token, which can be generated on your Medium Settings page, but other than that is simple to configure.
I’ve submitted it to the Workflow Gallery, so I’ll add a link if/when it’s approved.
If you’re reading this on Writing on Tablets, the generated Medium article is at https://medium.com/@yeltzland/a-workflow-to-upload-web-content-to-medium-writing-on-tablets-8e5798b8f56e#.49ymh1stz
10 Jan 2017
Big news this week is that Trello is being acquired by Atlassian for a whopping $425 million!
Now I like Trello a lot. I’ve used it for my own projects for a while, as have a few companies I’ve worked with recently. It’s got a nice interface, is easy to use with some powerful extensions and can be easily integrated into other systems to make it really useful.
However recently I’ve switched to using GitHub Projects for tracking my work items and I’m pretty happy about doing so.
GitHub Projects has a similar style Kanban card-based interface, but has no extensions and as far as I can tell, and the API
is currently only in Preview mode. The web interface is also slightly flaky in Safari on iOS.
So what’s to like? Well for me, the big advantage is that the work items are right next to the code in GitHub, so it’s really easy to find when you are working on multiple projects.
It integrates perfectly into managing issues via GitHub - great for my open-source projects, especially when following the GitHub Flow process using pull requests
Also, even though Trello is very extensible, I never really use those power features, and a simple Kanban board is enough for me.
I really hope GitHub do add a few more features to their Projects board - for example webhooks for when a card changes column, and the ability to assign cards to commits - but for now it’s good enough for me.
It’s interesting Atlassian recognise the potential synergies with their existing software management software too. However I’ve recently gone all in with using GitHub, and I’m really happy about that decision right now.