Singapore Transit is a free app with a single in-app purchase that removes ads and gives the user access to a few alternative icons. That model is not hugely successful when you've got running costs—for example, a push notification server—to support. As I work on splitting Singapore Transit into multiple apps, I've been contemplating different business models that I could implement.
First, though, I want to cover what needs to be supported:
- Database storage for device tokens, user push notification preferences, traffic incidents, MRT incidents, and digests of already pushed notification content
- Pushing notifications to multiple thousands of devices
Heroku currently hosts Singapore Transit's server with MongoDB and Redis add-ons. Heroku is a breeze to set up, but it does get costly very quickly. To that end, for the new apps I am building, I will switch to a Digital Ocean droplet with a significantly lower running cost.
A Renewable Subscription for Notifications and Ad Removal
The first model which I am considering is to place notifications and ad-removal behind a renewable subscription. During the period of subscription, a user will receive notifications of traffic incidents or MRT downtime and not see ads.
This first problem with this model is usefulness.
With regards to MRT service unavailability, in the two years that Singapore Transit has been in operation, there have been a total of 30 notifications for MRT incidents. That's 30 notifications covering less than ten episodes of service unavailability in two years. The MRT service is consistently excellent. (In comparison, I built a proof of concept for London Underground, which had more than 30 notifications in a week.) With that service stability in mind, is a notification subscription worth it? I'd say no.
Traffic notifications are slightly different. Thousands of traffic notifications are generated every day, from roadworks to obstacles, diversions to accidents. A notification subscription with these volumes seems to make more sense.
The second problem is profitability.
Push notifications are not an expensive service, and customers likely expect that if they are behind the paywall of a subscription, then that subscription will be cheap. I think a subscription to either MRT downtime or traffic incidents would top out at the S$ 0.98 tier. The deductions then start eating away at that S$ 0.98 like a flesh-eating bacteria.
In reality, that would mean :
- Customer pays: S$ 0.98
- Minus Apple's 30% commission: S$ (0.29)
- Minus GST @ 7% on commission payable to Apple: S$ (0.02)
- Payable to developer: S$ 0.67
- Then subtract income tax at 4%, and the result is S$ 0.63
If you assume running costs of S$ 7/month for a Digital Ocean droplet and S$ 140/year for Apple's Developer Program, then you end up with the following returns over a one month and one year period.
- 1 Month: S$ (194)
- 12 Months: S$ (123)
- 1 Month: S$ (136)
- 12 Months: S$ 567
- 1 Month: S$ 438
- 12 Months: S$ 7,466
- 1 Month: S$ 6,188
- 12 Months: S$ 76,456
I can make a profit with 100 subscribers after a year, but to make a reasonable second income, I would need around 5,000 subscribers.
The last problem is the purchase likelihood.
In the marketplace, the Land Transport Authority already has an app available that provides notifications for MRT downtime and some traffic alerts. That app is free, backed by a government body, and has no ads. The race to the bottom hasn't started, it's already finished.
Anecdotally, as I mentioned above, Singapore Transit has a one-off in-app purchase to remove ads, and very few people have purchased it. Furthermore, I've never received any complaints about the ads that are there.
Lastly, how many subscriptions of less than one coffee a month are customers willing to pay? I know I'm at the stage of I'd rather have the coffee, dammit.
Based on these conditions, I'd infer that placing notifications and ad-removal behind an in-app subscription is not worth it.
With no complaints received about the ads in the app so far, why not just keep them there permanently?
By carefully placing the ads—for example, using native display ads, instead of horrifying interstitials—I'd continue to respect the user without disrupting their flow. Some of the apps that I use—Overcast and Yahoo Finance—have nailed the usage of native ads.
Whether or not I'd always want ads in the app is an ethical one.
Ads help everyone win a little: all features are available, the customer pays nothing, and as a developer, I continue to make money. It's a preferable model to the in-app subscription model.
However, there's one more option that I am considering.
Ads Always with Optional Patronage
The last model combines ads always with patronage. This model gives me more work to do, long-term, for patronage paying customers.
What do I give these customers in return? Themes? Icons? Different notification sounds? I could conceivably give them nothing, but that would be not very kind.
Everyone continues to win in this model. Ads ensure the app can be free and have all features unlocked. An optional patronage purchase also gives generous customers a way of saying thanks with no strings attached.
When I started writing this piece, I had a strong inclination that by the end of it, I'd settle on in-app subscriptions. That's not turned out to be the case. For the particular series of apps that I am working on, that model doesn't stack up. In essence, there are other free apps in the marketplace with similar functionality and, as such, there is no impetus for a customer to subscribe.
I am going to progress with Ads Always, at least initially. If that proves successful, I will add optional patronage later on. With a slight compromise, everyone wins.