sub transmogrifyLinks() {}
⬜️ Cache invalidation
✅ Naming things
I think I’ve just about got this computer science thing whipped.
With other BaaSs adopting the Parse API to attract Parse refugees, Parse API could become a de facto standard, making BaaS interchangeable.
In October 2015, Pieter Omvlee of Bohemian Coding gave a great talk at the inaugural Release Notes entitled The Great Pretender: Pretend to be More Than an Indie. In his presentation, Pieter talked in part about his experience selling a professional app to professional users. One of the things he suggested is that indies should consider pretending to be a bigger company than they really are in order to instill confidence in the mind of the customer that they are a Serious Business™. He pointed out that professional, enterprise, and corporate customers don’t care that you’re indie. They don’t care that you’re “living the dream.” What they do care about is that you’ll be around to support the product they purchased for years to come. Your inspiring “against all odds” story may buy you credibility with your indie peers, but oftentimes it does exactly the opposite with your professional customers.
Pieter’s talk really hit home with me. After all, my company and his company have a lot in common. Sure Bohemian Coding has been way more successful than Metakite Software has been (thus far), but we both sell products to professional customers. Bohemian Coding sells Sketch to professional designers; I sell Benjamin to professionals of all stripes who who want to be more productive. In many ways, Bohemian Coding is a model for my long-term goals with Metakite Software. So when Pieter pointed out the way that his (and by extension, my) customers viewed indie developers, I sat up and took notice. I didn’t immediately act on his advice though.
(more…)
Anyone who’s even a little familiar with game theory is undoubtedly familiar with The Prisoner’s Dilemma. It’s a classic thought experiment that illustrates how people can make rational choices that seem to be in their own best interest, even when another choice would result in a better outcome for themselves and for the group.
In the classic formulation of the Prisoner’s Dilemma, the prisoner in question is faced with a choice. The prisoner can sell out his accomplice to the authorities and receive a lighter sentence in return, or he can remain silent knowing that there’s not enough evidence to convict without one of their testimony. The problem is that the prisoner’s accomplice is being offered the same deal. How much can the prisoner really trust his partner in crime? What if the accomplice takes the deal and leaves the prisoner to take on the full burden of the sentence? If the prisoner remains silent and the accomplice talks, doesn’t that make the prisoner a chump?
The central conflict of the Prisoner’s Dilemma comes down to trust. If the prisoner is confident that he can trust the accomplice, and the prisoner is confident that the accomplice is confident that the prisoner is likewise trustworthy, then both are better off (both individually and as a group) remaining silent. But if the prisoner isn’t completely sure that he can trust his partner in crime, or if he isn’t sure that his trust is reciprocated, then he’s better off singing like a canary.
So what does this all have to do with iOS developers? The iOS developer community has been locked in a game of the Prisoner’s Dilemma since the App Store was introduced in 2008, and we’ve lost at every turn. For us, the stakes aren’t whether we’ll go free or go to jail, but whether there will be a vibrant market for paid mobile software. Our choice isn’t whether or not to sell out an accomplice, but rather it’s whether we’ll choose short-term gains while at the same time contributing to the perception that mobile software isn’t worth paying for, or if we’ll forego those short-term gains knowing that a competitor could cash in and make our restraint all for naught. In short, it’s about the race to the bottom.
I used to think that the race to the bottom had reached as low as it could go. After all, what could be cheaper than free, ad supported apps? Turns out I was wrong. Recently, a monetization method that has been around for a while has become suddenly more popular and has taken the race to the bottom to even lower depths. Instead of providing content and requiring customers to pay with their attention by showing them ads, this new method gives everything away for free in the hopes that a small portion of customers will throw a few coins their way.
Proponents of this model call it “patronage,” but it has little in common with the historical concept of patronage where a well-off patron paid an artist an amount to commission a work of art. This new model, in fact, is the opposite of patronage. Instead of requiring a patron to provide money up front in exchange for an item of value, this new model gives away all the value in advance and requires nothing from those who receive it. It less resembles patronage, or even commerce, than it does begging, or busking if you’re feeling generous.
So how did we get to this point? One rational decision at a time. Over the years, thousands of developers have decided that it was in their interests and their businesses’ interests to lower their price and capture more price-sensitive purchasers. Many of them no doubt increased their revenue by attracting customers who would have otherwise purchased from competitors, which was exactly the plan. The unfortunate side-effect of this strategy, of course, was that customers were trained over time to expect mobile software to be free or low-cost. And once that expectation became set, it became incredibly hard to convince customers to part with even the smallest sum of money to purchase an app.
But I don’t blame those developers that contributed to the race to the bottom by selling their work at rock bottom prices. In general, they did act in their own best interests and the best interests of their businesses, and that’s how free markets are supposed to work. Just as in the Prisoner’s Dilemma, they had no way to know that their competitors wouldn’t try the same price-lowering gimmick, so the only rational choice was to preemptively lower their price to capture those price-sensitive customers. Even if a developer realized at the time that he was contributing to the race to the bottom and diminishing his long-term prospects in the App Store, the rational decision was still often to lower an app’s price and cash in first.
That’s the insidious nature of the Prisoner’s Dilemma: By the time you’re faced with a choice, it’s too late to take the high road. By the time the prisoner is being questioned, the only rational choice is to sell out his accomplice, because he can’t be sure of the other’s thinking. Likewise, by the time an app developer faces the choice of lowering his price or holding the line, the only rational choice is to lower his price and cash in first, because if he doesn’t, a competitor will. And so, step after step, price drop after price drop, the cycle continues until we arrive at the situation we find ourselves in today where we give away months of labor gratis in the hopes that a few customers will take pity on us and drop a couple coins in our hat.
The good news is that we can break this cycle, but only if we engineer our businesses to avoid competing on price in the first place. We can avoid competing on price by choosing to build apps that are truly differentiated from their competition. We can avoid competing on price by choosing app ideas that present a barrier to entry (legal, technical, or otherwise) to prospective competition. We can avoid competing on price by entering niches that are less price-sensitive than the mass market is. We can avoid competing on price by carefully considering and analyzing the financial viability of prospective apps before ever opening Xcode. In short, we can avoid competing on price by treating our app businesses as a business and doing the up-front work that’s needed to ensure that a prospective app idea is a sustainable one.
A friend of mine, Curtis Herbert, has been writing a series of articles (1, 2, 3) he calls Slopes Diaries about the development and pricing of version 2 of his app Slopes. Although I’ve found Slopes Diaries to be interesting, and while I agree with a lot of what he’s written, a few things that he wrote in his most recent installment of the series struck me as wrong.
Curtis begins Slopes Diaries #3 by quoting himself from Slopes Diaries #1, “Lesson learned: Charge more. Then double it.” He then continues:
After that lesson you might expect I’d announce I’ll be raising my price to $49.99 with v2.
Nope.
I’m going free up front with Slopes 2.
Why would Curtis make Slopes free after earlier citing “charge more” as one of his lessons learned? He gives three reasons in his post:
- The first reason, he refers to as “The Acquisition Barrier”: “One of the biggest barriers to entry for someone to try my app is having a price on it.”
- The second reason, he refers to as “The Churn Barrier”: “Eventually, I’m going to saturate the market of people willing to pay up front for my app.”
- And the third reason, he refers to as the “The Survival Barrier”: “Here’s the thing: if I want any kind of serious chance to grow this into a business and do more for my users I need to find a way to charge more. My current price of $7.99 would be considered by many a premium price point, but even at that I have practically no money for user acquisition through advertising or customer support.”
While I completely agree with his third reason—he does need to increase his revenue per user if he wants to grow his business—his first two reasons for going free are almost certainly wrong. But he’s not the only one that believes them. I’ve seen these same justifications trotted out by other independent developers as well, so I want to take a moment to refute them.
The Acquisition Barrier
Let’s start with the first reason, “The Acquisition Barrier.” Curtis claims that an up-front price is the biggest barrier to entry for his app. I don’t think it is.
According to the SnowSports Industries America (a snow sports trade association), there are an estimated 13,000,000 adults in the United States who ski or snowboard in 2015.1 According to the Pew Research Center, 64% of American adults own a smartphone.2 According to Forbes, the iPhone accounts for 36.5% of smartphones in the U.S.3 Multiply those together and you end up with an estimate of the number of adult skiers in the United States who own an iPhone: Over 3,000,000.
Compare that figure with Slopes sales last year. According to Curtis, Slopes had about $10,000 in sales last year.4 Since Slopes sells for $7.99, that means Slopes sold about 1,250 copies last year.
It’s clear that Slopes has a lot of fans, but there is a lot of room for growth. Slopes’ 1,250 sales last year mean that it has penetrated only four ten-thousandths of the addressable market. There are millions of adult skiers in the U.S. that haven’t purchased, and have probably never even heard of, Slopes. This leads me to believe that up-front pricing is not, in fact, Slopes biggest barrier to entry. Customer awareness is.
The Churn Barrier
Now let’s talk about Curtis’ second reason for going free, “The Churn Barrier,” in which he fears that he will eventually saturate his market of customers. While I concede that is mathematically inevitable, I don’t think that’s the issue Curtis should be most concerned about at this point. Slopes sold 1,250 copies last year. At that rate it would take 2,400 years to saturate his addressable market. Even if Slopes experienced 10x growth next year and started selling 12,500 copies per year, it would still take 240 years for Slopes to saturate its addressable market. Simply put, even if Slopes experiences a sharp uptick in sales, its developer will be dead and in the ground before market saturation becomes an issue.
The Survival Barrier
What I find most interesting about Slopes Diaries #3 is that Curtis’ third reason for going free, “The Survival Barrier,” gives tacit acknowledgement to the fact that the root problem of Slopes’ sustainability is not in fact the two reasons that are explicitly stated, but rather that Slopes can’t effectively reach its target market to acquire new customers.
Inability to reach the target market is a real problem and one that many indies, myself included, struggle with. Charging even a relatively high price (by App Store standards) of $7.99 ($5.60 after Apple’s cut) doesn’t make it worthwhile to advertise, market, and generally do the things that need to be done in order to attract customers. The cost of customer acquisition is simply too high compared to the revenue per user.
The solution to this, as Curtis acknowledges, is to increase the average revenue per user. There are many ways to do this, and Curtis has apparently chosen to go with some variation on a freemium or subscription model. Those can certainly work (I use them myself) and it very well might be the best solution for Slopes, but I’d like to close with a look at a strategy that Curtis acknowledged, but dismissed: paid up-front premium pricing.
Charge More. Then Double It.
In Slopes Diaries #3, Curtis quickly considers increasing his paid up-front price, but just as quickly dismisses it:
I know the value of my app: at the end of the day Slopes is considered entertainment. Fairly so as I’m not making my users money with it. If I raised my price to say $50 to increase my revenue per user I’d lose so many sales that I’d have less revenue coming in monthly.
I’m not so sure. Curtis knows his customers better than I do, but I think the $50 price point he mentioned is interesting, at least, as a thought experiment.
First let’s consider the feasibility of a $50 price point. Skiing is an expensive hobby. Doubly so for those serious about it. Skiers have to pay for transportation, lift tickets, equipment, special clothing and more. But the fact that they’re skiing is proof that they’re willing and able to pay those costs. Skiers are a self-selected affluent market.
According to SnowSports Industries America, skiers spent over $4.5 billion5 on clothing, equipment, and accessories last year. That’s a lot of money. I bet there’s a lot of people who would consider $50 to be a reasonable investment to permanently document their day skiing and have tangible evidence of their bragging rights.
So now let’s imagine how re-styling Slopes as an app for “prosumer” skiers at a $50 price point might change Slopes’ business model. Most obviously, with no other changes, Curtis could almost certainly expect fewer sales. But as long as sales were more than one one-sixth their previous level, Slopes would still be making more money than at the lower level. But who says that nothing else must change? At $50 per download ($35 after Apple’s cut), that gives much more room for user acquisition. How might Curtis make use of that extra revenue per user? Google ads? Facebook ads? Podcast ads? Physical signage at ski resorts? Ads in ski-related newsletters? All of these seem like real possibilities when each sale brings in at least $35 in revenue.
Charging a higher price could provide a solution to the biggest problem that Slopes (and most indie apps) face—customer awareness. It could give Curtis a way to reach a larger, more valuable audience, and help him overcome the “survival barrier” that he identified.
Wrapping Up
To be clear, I don’t take issue with Curtis’ stated intention to take Slopes free with version 2. I have no insight into his business, or his plans. It very well might be that going free with Slopes (presumably with some sort of in-app purchase or subscription), is the best course of action. What I do take issue with are his stated reasons for going free. I take issue with them not to belittle Curtis or his app Slopes (it’s a well made app that’s functional and stylish), but rather to hopefully counter some misguided business thinking that seems to be common among indie developers.
I wish Curtis nothing but the best of luck with Slopes. I hope he find success, and is able to find a market that is willing to pay for the clear value that he’s providing. If you’re a skier and you’ve read this all the way to the end, you might consider supporting a fellow indie by buying his app.
Snow Sports Fact Sheet Note: I assumed that 50% of snowboarders, freeskiers, and cross country skiers were double counted, since no total numbers were provided. ↩
Apple’s iPhone Continues To Lose Market share Month to Month ↩
Since posting My Delivery Truck, I’ve gotten a lot of responses, both on Twitter and (in the best tradition of blogging) reply posts. Although many were supportive of my post, some developers took me to task. A lot of the same objections were raised repeatedly, so I’m going to concentrate on a blog post from Aleksandar Vacić titled Store your Love which nicely summarizes many of the objections that were raised.
Aleksandar writes:
The iOS App Store is not just a delivery truck. For starters, it is the delivery truck, the only one out there.
The App Store is the only marketplace where you can compete as indie iOS developer. As such, the way it works and behaves strongly influences everyone’s business on it.
The App Store is also your storefront which, for some time now, strongly favors early comers and big-budget apps not interested in earning money.
The App Store is also a dominant discovery truck where it fails spectacularly due to its abysmal catalog search.
The fact that there’s no viable way to re-monetize your existing customer base [such as upgrade pricing] severely limits available business options.
All of these things are true. In many respects, the App Store is hostile to individual developers. Unfortunately, we have to deal with the App Store the way that it is, not as we would like it to be. In the end we have two choices: compete in the App Store despite its hostility, or get out.
Yes, we should recognize the limitations of the App Store and suggest improvements, but we can’t count on those improvements being implemented. Most of the complaints that Aleksandar raises above have been pointed out time and time again over a span of years. And yet these limitations remain.
And yes, we should study the App Store so that we can better understand its behavior. Understanding the quirks of, for instance, the App Store’s broken search algorithm can help us optimize our App Store presence. But what happens when Apple changes that search algorithm? What would happen to all the apps with keyword optimized titles if Apple decided tomorrow to penalize apps with “spammy” titles in search results? Building your business based on the quirks of the App Store is like building on sand. You’ll never have a strong foundation beneath you.
So if the App Store has all these problems that Apple has shown no interest in fixing, and if it’s not safe to build our business based on the quirks that the App Store happens to have today, then what’s left?
What’s left are the fundamentals of running a business. Carefully choose a market that will pay for the value you provide. Plan from the beginning to market your app outside the App Store. Use the permissible payment methods to engineer recurring revenue into your app. What’s left is building your business on only those aspects of the App Store that you can rely on – payment processing and software delivery. Essentially, what’s left is treating the App Store as merely your delivery truck.
As tends to happen in regular cycles in our community, there has recently been another bout of handwringing over the difficulty of making it as an indie. Brent Simmons kicked this one off in his well written piece titled Love. And I don’t mean to make light of his piece. If you haven’t done so, I encourage you to read it. It encapsulates well a lot of the emotional angst that many independent developers are feeling about their businesses right now. Things aren’t as easy as they once were – especially in the App Store. As everyone in this business knows, supply is up (there are hundreds of thousands more apps in the App Store than there were just a few years ago), and prices are down. The App Store is no longer the land of milk and honey that it once was. As a result, we complain about it. A lot.
“The App Store is hostile to indie developers.”
“People won’t pay money for apps on the App Store.”
“The App Store should do more to help customers discover my app.”
But you know what? We developers need to get over it and stop blaming the App Store for our business troubles, because when it comes down to it, the App Store has only two purposes: credit card processing and software delivery. That’s it. Yeah, I know the App Store was originally sold to developers as a marketing channel, but it hasn’t been that for many years.
Today, the App Store is basically your delivery truck that takes cash on delivery. We wouldn’t blame a delivery truck for our business failure. It doesn’t make any sense. It’s not a delivery truck’s responsibility to ensure that there’s a market for our products. That’s what market research is for. It’s not a delivery truck’s responsibility to advertise our products or introduce them to customers. That’s what marketing is for. And it’s not a delivery truck’s responsibility to prop up prices in the market place. That’s just not it’s role.
So the next time you hear a developer complaining about the App Store, mentally replace “the App Store” with “my delivery truck” before evaluating the reasonableness of the complaint. As I think you’ll see, most complaints about the App Store just don’t hold water.
“My delivery truck is hostile to my business.”
“People won’t pay for apps on my delivery truck.”
“My delivery truck should do more to help customers discover my app.”
Instead of blaming the delivery truck for our business problems, we need to double down on the business side of our software businesses. We need evaluate the market for an app before building it. We need to go to where our customers are and market our products outside the App Store. We need to research whether customers would actually pay a sustainable price for our app – before we even open Xcode. We need to take responsibility for our own success and our own failure and stop blaming the delivery truck for our problems.
Note: I’ve posted a follow-up to this article titled, My Delivery Truck (2nd Delivery Attempt).