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).
If you had asked me yesterday which Swift would be the topic of conversation among iOS and Mac developers today, I would have put money on it being the programming language and not the music star. And I would have been wrong, because Taylor Swift set the world of Apple watchers abuzz today by airing complaints about Apple’s new Apple Music service on her blog. In her post she lays out a well-reasoned argument that Apple Music’s payment policy is unfair to artists since creators aren’t compensated for listens by Apple’s customers during a three month trial period. As a result, she explains, she will not be releasing her newest album on the service. After reading Swift’s post and the resulting banter on the Internet, it’s tempting to dismiss the entire argument with some handwaving. “Of course Apple’s payments are unfair to creators. The entire music industry is built on exploiting creators. So get over it, because it’s a better deal than you’ll get from anyone else.” But forward thinking developers should take notice, because this controversy may hit closer to home than they expect.
First, no one is saying that Apple is doing anything legally wrong. They negotiated a contract with terms that are favorable to them. That’s what big companies do. And Apple will have every legal right to stream most artists’ music without compensation during that three month trial. So no one – not even Taylor Swift – is saying that Apple is breaking any laws. What Swift is saying, and what I agree with, is that it’s a bad deal for artists. Creators should be compensated for the use of their creations.
This debate is important to app developers because, whether we like it or not, digital music has been devalued – just as our digital creations have been. In just a few short years people have gone from paying tens of dollars for an album, to paying 99 cents for a single track, to paying pennies or even nothing to stream an entire library of music. This parallels in a rather frightening way the history of the App Store where, in an even shorter amount of time, mobile software that once sold for tens of dollars now is lucky to sell for 99 cents. Just as the music industry, now including Apple, has moved to an “all-you-can-eat” subscription model to bring down the per title cost of music below that 99 cent threshold, it now doesn’t seem unreasonable that a similar all-you-can-eat subscription model might be used to allow per title pricing of apps to fall below 99 cents as well1.
I think that such an all-you-can-eat subscription deal would be disastrous for indie developers, but a full explanation of my reasons for that belief is more than I want to tackle today. Today what I want to point out is that this fight for fair compensation is not just a fight for musicians. It’s a fight for software developers as well. Apple is a great negotiator, and the company will take everything that it thinks it can get away with. Our problem as developers is that we’re in an even worse position than a lot of musicians. Musicians at least have alternate channels for their work. iOS developers only have one – the App Store. Mac developers who distribute solely through the App Store are in a similar position. If you don’t think that Apple would impose similarly unfavorable terms upon its developers when it’s Apple that holds all the cards, you’re fooling yourself.
So if you are a developer who thinks that apps may one day be subject to a similar all-you-can-eat pricing model, it’s in your interest to lend your voice in support of Swift’s argument, because the terms under which musicians work may one day be the model for the terms under which you work as well. Tweet about it. Tell your friends. Lend your voice in support of the notion that digital creations have value for which their creators should be compensated. And after you’ve done that, start investigating ways to strengthen your own position. If you’re an iOS developer, start looking at ways to take your app to Android. If you’re a Mac developer, investigate Windows. And everyone should probably be looking at web-based software as a service. Start making plans now for a day when you might have to bravely say “No” to a bad deal, just as Taylor Swift has done.
Credit to Dave Wiskus for first putting this idea in my head. https://twitter.com/dwiskus/status/607977149560033281 ↩
I was reminded recently of episode #216: The Hustle of David Smith’s excellent Developing Perspective podcast. “Reminded” isn’t really the right word, though. It’s more that it’s stuck with me since I originally listened to it in April. In that episode, David talks (among other things) about the importance of hustle for an indie developer. And he’s right. Hustle is an essential part of indie life.
As an indie, you have to always be on the look out for the next opportunity. When you find it, you have to grasp it. And when you don’t, you have to manufacture it. You’ve always got to be looking for the next client, the next line of business, the next marketing opportunity. You’ve got to hustle. You’ve got to recognize and exploit any advantage you have over often larger competitors. And even when you don’t find opportunity or advantage – especially when you don’t find opportunity or advantage – you’ve got to take steps to create it.
Indies need to create those opportunities and advantages because they don’t have a lot of room for error. Pick the wrong product at the wrong time, and you’ll soon find yourself looking for work. Pick the wrong client or the wrong rate, and you’ll find your contracting business in peril. Hustle is a force multiplier. It gives you wiggle room to recover from a mistake. It gives you another path to pursue when a door shuts in your face.
I didn’t use to think that I had hustle. If you had asked me 10 years ago, “hustle” wouldn’t have been a word that I would have used to describe myself. But, as it turns out, I was wrong. Over the last several years, particularly since I started my business, I’ve discovered that I hustle pretty well. But if you don’t, don’t worry – it’s a learnable skill. Keep an eye out for areas of expertise that you have access to, and then brainstorm products that might come from them. Look for an audience for your product or service, and then approach that audience. Find resources you have access to, and then use those resources. In short, find your advantage and then take action. Today.
If you’re a U.S. taxpayer with apps on the iOS or Mac App Store, you may have received from Apple a Form 1099-K, Payment Card and Third Party Network Transactions, which reports to the IRS your gross revenue from App Store sales. You may have also noticed that the amount reported on your Form 1099-K doesn’t bear much resemblance to the payments actually received from Apple.
There are a couple different reasons the amount Apple reported might not match the amount you received. First, the payments that are reported on From 1099-K are gross payments that you received before taxes, fees, and (notably) Apple’s 30% cut. Second, the amount on your Form 1099-K may not represent your worldwide revenue. Apple only reports revenue on Form 1099-K for regions that have more than 200 payments and more than $20,000 in total gross payments in the year. Because the thresholds are reached on a region-by-region basis, you may exceed those thresholds (and thus have your revenue reported on a Form 1099-K) for the U.S. and Euro Zone, for example, but not in India or Russia.
As you can see, it all gets very complicated, very quickly. In theory, the amounts reported by Apple on Form 1099-K should be able to be reconciled to payments received from Apple using the financial reports available in iTunesConnect (since those reports list every sale, its region, fees, currency conversions, and more), but in practice this is a task that is beyond most developers. Most independent developers I know look at the Form 1099-K when it arrives, scratch their heads a bit, and then move on.
The problem with that, of course, is that Form 1099-K is an official tax document that is sent to the IRS, and when the IRS sees an amount of revenue reported, it expects to receive tax on that amount. So if you find yourself in the situation where the amount reported to the IRS on Form 1099-K is more than the amount you reported on your income tax return, you can expect that some questions will be asked. You might even find yourself with an extra tax bill.
Apple only began issuing Form 1099-K to App Store sellers starting with the 2013 tax year. (Affected developers would have received their first Form 1099-K in January 2014.) So until recently, any problems that developers may have faced because of discrepancies between amounts reported to the IRS by Apple and those self-reported by the developer were only theoretical. That may be starting to change, though:
So what’s a confused developer to do? How should you deal with a Form 1099-K that doesn’t seem to match your payments from Apple? Well, first of all, get yourself a good accountant if you don’t already have one. I recommend finding a Certified Public Accountant that deals regularly with small businesses. You might also want to start reporting your revenue gross with an offsetting expense, instead of net. In other words, instead of recording a $7,000 payment in your books, you might want to record $10,000 in revenue with a $3,000 expense that represents Apple’s 30%. This should prevent the troublesome situation where Apple reports more revenue to the IRS than you do. As always, though, don’t take my word for it. Ask your accountant.
For more information about Form 1099-K, see the IRS’s 1099-K FAQ or the Instructions for Form 1099-K. For more information about Apple’s policies regarding From 1099-K, see the Banking and Tax FAQ in iTunesConnect.