The world is crying out for decent post-PC smart devices. In response the industry is producing terrible products that would never see light of day in any other product category.

How do we know the world is crying out for decent products? The iPad. In 15 months the iPad was making more money for Apple than their entire Mac business. This is unbelievable. The iPad is a very nice product, but it isn’t that great. More accurately, it is good. And almost everything else is abysmal.

Abysmal, in that return rates for tablets are routinely measured in double digits. In that most products ship with egregious bugs that we would never tolerate in other product categories (and that are often magically solved in a software update). In that many products ship with performance issues that clearly make them unusable in their primary use case (e.g. phones with less than a day of usable battery life). And perhaps most of all, in that even the simplest tasks are hard to perform by all but the most expert of users.

Why is this happening? For decades the industry has been producing good PCs. They aren’t perfect, but most people buy a PC and get good use out of it for a quite a long time. Why are phones and tablets so different?

The Last Universalist

Consider the following: Every single engineer at Microsoft could go home tonight and build a PC from components, install an OS and give it to their parents. It would work and it would be useful. Mom and Dad would do email and browse the web and occasionally call the engineer for some simple tech support.

In contrast, not a single engineer at Microsoft could go home and build a phone. Forget for a moment the major issue of getting the components. Let’s say one could pick up everything you needed at Fry’s, including the enclosure. I’m saying that not a single engineer has all the skills and knowledge required to build a phone that a consumer would actually use.

I used Microsoft engineers in my example, but the same thing could be said of Apple engineers, Facebook engineers, Google engineers, and probably every engineer in the Valley. The point? There is a massive difference in complexity between a phone and a PC. No-one you know can build a phone. No-one you know can help you to fix one. You’re more likely to have a person in your family that can fix your BMW than you are to have one who can fix your Droid.

Now, part of the reason our engineer can’t do this is an issue of packaging. Phones are smaller and a lot of engineering goes into jamming all that electronics into such a small space. But that is only part of the story. We know this because few companies seem capable of making a good phone, or a good tablet, or even a good set top box. The real story is that the internal complexity of our post-PC smart devices is out of control.

This makes me think of Henri Poincaré, a 19^th century mathematician. He was considered to be the Last Universalist, that is, the last human being who was considered to have excelled in all fields of the discipline. I remember the moment I became aware of this because the thought that mathematics had grown to a point where individuals could only ever hope to grasp a piece of it was fascinating and a little scary. Think about that. As we learn more and more about math, it doesn’t get simpler, it gets more complex. The more progress we make, the less any individual understands of the whole. At the same time, our increased collective understanding allows us to build more and more complex things. There’s the scary. None of us understands these new wonders completely.

Even we make our products more simple for users, they get more complex inside.

The PC: Simplicity through Standards, by Mistake

Although the PC is an extra-ordinarily complex object, an historical anomaly made it simple. A standardized architecture with well defined interfaces emerged, creating uniform, industry-wide abstractions that tamed the inherent complexity of a computing device.

This wasn’t intentional. From IBM’s perspective, it was a series of incredible missteps in business strategy and managing their IP that allowed one company to create a uniform software platform and several others to copy their way to greatness with hardware clones. By mistake, the PC became a seldom achieved win-win outcome in a game of prisoner’s dilemma.

And to prove that lightening does strike the same place twice, we have the Internet as a second historical anomaly.

As fantastic as the win-win results of the PC and the Internet were for everyone involved, even IBM, we are unlikely to see this happen again in our lifetimes. The steady state outcome for prisoner’s dilemma, after all, is lose-lose. In this context, lose-lose means that companies generally fight to keep advantage through proprietary technologies and interfaces, and we never see the massive forward momentum that is generated for the industry as a whole when win-win open standards emerge.

But in the lose-lose outcome, most consumer electronics products are internally a complex, proprietary mess. One of the hidden benefits of an open standard is that it stops talented, well meaning engineers from reinventing interfaces to make them slightly better. Even if internal standards exist, few companies have the discipline to hold to them, so much of the complexity is reinvented for every product cycle. Not because engineers and management are bad, but because they are ambitious and unconstrained.

Solution 1: Forcing the Standard

Is Android, an open-ish platform, the answer in the quest for standards when it comes to phones? Not really. It is a software standard of sorts, but the standard runs only skin deep. There is no corresponding hardware standard (e.g. no equivalent of the PC BIOS) that constrains hardware design. Instead, every new phone has its own “board support package”, a non-standard layer of software than tries to abstract away hardware differences. Then the OS must also abstract away more differences. The result is compromised performance and compromised reliability.

Of course, the sheer number of new Android based phones will probably generate some really good ones along the way. But it would be surprising to see any of these individual examples become great product lines that stand the test of time.

Windows Phone 7 does better than Android at taming complexity by being more restrictive on hardware, but until WP7 has market scale, this just means that phone OEMs will focus on Android as their primary vehicle for differentiation. WP7 will stay a side project. Hence Microsoft’s need to do a huge deal to get Nokia’s full attention. If they can leverage this into scale, then they might be able to use that scale to create some hardware standards. This is the scenario where Microsoft makes an incredible comeback. It isn’t likely, but it is possible and it is the reason that ruling them out completely is short sighted.

Solution 2: An Obsession with Simplicity

Apple masters the complexity through an incredible discipline of simplicity at the product line level. Any other company would, by now, have diversified the iPhone’s success into a proliferation of SKUs. Just consider the number of times since the iPhone’s launch that smart people have been predicting smaller iPhones, bigger iPhones, iPhone Nanos, iPhone shuffles. It never happened. Why? Apple understands the role of product line simplicity in taming engineering complexity.

I should also point out that although I have focused on engineering complexity, this is really only part of the picture. Business complexity is arguably just as important and debilitating, particularly in an industry where players like mobile operators, content providers, and the distribution channels have colliding business models that are all in various stages of disruption. But just as product line simplicity helps to Apple tame engineering complexity, it helps them to deal with business complexity. With a single popular product, Apple could out negotiate these other players in ways that OEMs like Nokia and Samsung could never do with larger, but fragmented product lines.

Other companies will get there in time with Apple’s soup to nuts approach. Google might do so by digesting Motorola Mobility and becoming more like Apple. Perhaps completely new OEMs, like Amazon, will emerge and join Apple in replacing the old guard. After all, the bar is so low that even Barnes & Noble can create a credible competitor to the current line-up of products in that market so well-loved by analysts — tablets sans iPad.

And Apple’s continued success is anything but certain. They could so easily lose their way and let the complexity sneak in, especially in a competitive environment where the bar is so low. Hopefully Steve Jobs’s unique understanding of the importance of simplicity at every level is so ingrained in Apple’s culture that it survives his passing.

The reality is that for the next decade there will be some good products from Apple, some isolated brilliance from other manufacturers, and for the rest, a sea of crappy products to choose from. What a perfect time for hardware-savvy startups to make a comeback.

On the right is a selection of Liquorice Allsorts, a product where choice is a key feature. Everyone has their favorite, but there is something wonderful about finding it amongst the others. People share a bag of Liquorice Allsorts, and different people have different favorites. The variety keeps things interesting and leads to the consumption of far too much candy.

Phones are not like Liquorice Allsorts. You don’t buy a bag of them and use a different one each day. Typically, you buy one phone and then use it for a long time. You don’t buy a phone and share it among a group of people. Typically, you are the only person who uses your phone. “Choice” is not a feature of a phone. Choice can be a feature of a category of phones (e.g. Android phones), but you don’t use a category of phones. You use a single phone.

So when Microsoft and Google say that they offer consumers “choice”, they are either misunderstanding consumers or misrepresenting their reasons for providing choice.

To be sure, there are some good reasons to offer choice.

1. Choice increases your addressable market. One could make a strong argument that iOS and Android will start tapping out the addressable market for phones with an iPhone like form factor. There are people that would prefer a physical keyboard, for example, and when the only new market left is these people, then Android will benefit from that.
2. Choice increases your distribution opportunities. If your strategy is to provide an OS and partner with many different OEMs or Mobile Operators, then supporting many permutations will help you. You can use some permutations to create unique offers with certain partners. And you can accommodate their varying points of view on what features are necessary to win. Even Apple with its vertical strategy could get more distribution if they offered more choice.

Choice also, however, comes at a price. Things like supporting another screen size, or having a version with a keyboard, sound relatively simple to many dinner party pundits. Even to professional pundits. But they have MASSIVE consequences for messaging, user experience, risk, cost and productivity. So there are also good reasons NOT to offer choice:

1. Choice reduces the clarity of your message: It is hard enough to get people to understand a complex consumer electronics product without explaining a bunch of permutations. Apple understands this and is fanatical about keeping its product line simple. One form factor, one input method, one screen size, one app store, one OS release for all devices. It took incredible discipline to keep things this way.
2. Choice compromises user experience: Supporting a physical keyboard on iOS would require the experience to be rebuilt from the foundations up, and the result would probably never reach the quality of the current iOS with its focus on the touch screen. UX design is a constant trade off between simplicity and the desire to add features. That is why, even with the worked example of the first TiVo UI, no company, not even TiVo themselves, could build as delightful a DVR experience. Supporting choice means creating products where the ratio of total features to features actually used is larger. In other words, more complexity without more value from the perspective of an individual user.
3. Choice increases hardware costs (and risk): The fewer components you have in your product line, the better. It is easier and cheaper to manage your inventory. And more importantly, fewer distinct components spread over the same product volume gives you more leverage when negotiating prices with key component suppliers. Apple has even taken this to a point where they can lock up world supply for a particular component. This is called buyer power. Without it, you will pay more.
4. Choice increases software costs (and risk): Building something with 3 options is much more than 3 times as hard as building something with one option. Every option that is added to a product contributes to a geometric increase in the complexity of the code base. This is completely lost on most product managers as they complain “how hard can it be to add that ONE additional checkbox!?”. Not hard, but once it is there it will be a gift that keeps on giving as it influences and constrains the rest of the system. Immediately, but also for years to come as the product evolves.
5. Choice is a productivity sink: More meetings. More email. More hallway discussions. More support requests. Every little permutation that gets added to a product has an impact on managers, engineers, marketing, support and almost everyone else in the organization. Viewing each person’s activity as doing, the actual creating of value (designing a feature, writing ad copy) and coordinating, talking to other people about what you should do or how you should do it, each new option you add reduces the ratio of doing to coordinating. It can get so pathological that not only do management roles become 99% coordination, but the organization needs new, non-management roles held by smart, creative people that do nothing but coordinate.

There is another effect that has been documented, but is less definitive. It seems that having more options can undermine our ability to make a decision. Sheena Iyengar’s research (which I found via John Gruber’s Daring Fireball, and which was the spark that lead me to writing this post) included an experiment where people were six times more likely to buy a jar of jam if there were 6 options than if there were 24 options.

I experienced this myself when I had to buy an Android phone for testing our app. After reading countless reviews and visiting several stores I was stumped and ended up putting off the decision for a couple of months. I was finally forced to pull the trigger when we were running out of time, so I closed my eyes and clicked “add to cart” for the Google Nexus. The difference between this and the decision process when choosing an iPhone couldn’t be more stark.

My list of “choice” cons is not exhaustive, but I think it will be sufficient to make the point that building choice is very costly. And since choice doesn’t have any material value for the user after they have purchased their new phone, it should only be built if the addressable market and distribution needs justify the investment. Is this the case for the two main proponents of smartphone choice, Google and Microsoft?

Google, yes. Relative to Apple, user experience is lower in their stack of priorities (this isn’t a criticism, merely a necessity of their horizontal strategy), so they can stomach the UX cost more easily than Apple would. Their volumes depend on serving many, many partners (both OEMs and mobile operators), so pushing distribution as far as they can is important. And they have enough market share that they probably should be at least thinking about what happens when the addressable market gets more tight.

Microsoft, no. With less than 2% market share, Windows Phone is nowhere near the point that addressable market or distribution reach are limitations. And the fidelity of the OS experience suggests that UX is high on their list of priorities. So as a Microsoft shareholder and a fan of Metro, I would love the company to concentrate on one, small part of the market and win there convincingly. The consumers they target won’t care one bit about choice, only that there is this one phone that excites them way more than any other. Before Windows Phone has this sort of localized traction, any effort on increasing the addressable market or opening more distribution channels will not only be wasted, but it will take resources away from the goal of winning in at least one corner of the market.

Which brings me back to my starting point. Phones are not like Liquorice Allsorts. Choice is not a feature. It only has real meaning from a supplier’s perspective. It can give Google or Apple or Microsoft more addressable market or more distribution reach. Demand side value, however, is about millions of individual consumers, where all that matters is meeting each of their individual needs. And all that takes, in each individual case, is one great phone.

—

Disclosure: I was a Microsoft employee and I still own Microsoft stock.

Very few of Apple’s product introductions are breakthroughs from a pure technology standpoint. Anyone working in Microsoft, Google, Nokia or any one of a dozen other technology companies had seen everything in the first iPhone before Steve unveiled it. What they hadn’t seen before was a user experience that brought it all together in such an utterly useful and compelling way, with a marketing campaign that clearly focused on the benefits and retail distribution that is remarkably good at educating people about new product concepts.

That is Apple’s unique ability. Packaging of newness. Nailing user experience. Messaging it in a simple way. It is innovation, but UX and marketing and retail innovation more than technology innovation. Put differently, it is useful innovation.

But even Apple struggles to convey the significance of software innovation sans sexy new hardware. We human beings have not evolved as fast as the technology we have created and for most people, hardware is more impressive than software. Most of us have our thoughts grounded in the physical world, not in the abstract world of algorithms and data.

And before you think I’m talking about the naïve masses: I’m not. This is not about technical sophistication. I spent almost two decades — first in industrial R&D and later in consumer devices — working on very early stage projects. I have done countless presentations and demos. And no matter who the audience was, if I had an actual physical piece of hardware to show them, then I was an order of magnitude more likely to get funded. Even the most seasoned software executive couldn’t just “imagine what this would look like in a cool case instead of on my crappy hardware mockup with exposed wires.”

So here’s the reality that’s playing out after Apple’s announcement yesterday. No matter WHAT Apple introduces in their software — it could be living, self aware artificial intelligence — people will grumble if that new software is not built into a sexy new physical form factor.

They will blame Tim Cook (only months into the job) for the update being “incremental”. They will talk about Apple’s “fall from grace.” Some of these are emotional outbursts based on disappointment. Others are just attempts to find the most extreme or newsworthy hook. But all of these ridiculous points of view have one thing in common: they are only credible because we human beings still struggle to see software as “real”.

So why not just make the phone look new every time? There are many good reasons why you wouldn’t do that if you were Apple, and here are a few of them:

• You don’t want to make current owners feel bad. They’re probably halfway through a two year contract. Even with the iPhone 4S in market, the 4 still feels new because it looks the same.
• You don’t want to make potential owners skittish. Let’s say for argument’s sake that for most people will wait for a new model if the current model has less than a 3 month window remaining. If new models appear every year, then that is 25% of the cycle. If they appear every 2 years, then it is 12.5% of the cycle.
• You want to maintain iconic status for the object. This is harder to do if it is changing frequently. The longer a product is in market, the more easily identifiable it becomes. If the iPhone looked new and different every month, our ability to see it “in the wild” would be the same as our ability to spot a Samsung phone in the wild.
• You want to maximize margins. A big part of this is keeping the hardware constant, because the tiniest changes have massive cost implications. There is the (loss of) economies of scale in component procurement, the cost of redesign, the cost of retooling a production line, and the period of ironing out teething problems and “settling in” to a new product. These are the main costs, but there are many others. Even something as prosaic as having to change the product photography in every piece of marketing material is significant.
• You are building suspense for the next form factor update. Frequent updates will undermine the impact of a new form factor. We’ll soon lose interest if Apple responds to our temper tantrums about no new form factor and starts to update the iPhone more frequently. After the first couple of 6-monthly form factor updates, we’ll be “Meh, another beautiful iPhone.”

It is a balancing act, and one that Apple is managing in a masterful way. They are not sitting in Cupertino worrying about the current wave of “no iPhone 5″ angst. They are embracing it, because they know that the wailing and gnashing of teeth is evidence that the iPhone is still the king of gadgets and everything is going according to plan.

None of this is to say that I didn’t want a new iPhone 5. And I hope it is coming soon. I am only human, after all.

—

See also: No iPhone 5 this Year? Suck it Up!

When I wrote about recurring payment solutions in March I called Saasy “without doubt the simplest recurring billing payments solution the world has ever seen.” I thought it was expensive though, and it doesn’t have data portability. You can’t move your customers’ credit card data to another provider. You are locked in.

Braintree was my overall favorite of all the options I looked at. Their cost was very reasonable and they are strong advocates of data portability. Having now completed the integration with our app I can say based on first hand experience that their API is easy to use and nicely thought out. Their transparent redirect is a clever way to eliminate most of the PCI compliance hassles associated with taking credit cards.

Stripe, which launched a few days ago, might have changed everything. It takes simplicity to a new level at what appears to be very low cost. They charge 2.9% of your transaction fee plus 30 cents per transaction. Nothing else. In their words:

No setup fees, no monthly fees, no card storage fees, no hidden costs: you only get charged when you earn money.

In reality there is one other potential cost: a $15 chargeback fee when someone reverses a payment.

I have updated my Recurring Payments Cost Calculator, so if you are looking for a subscription billing solution you can see for yourself how Stripe compares to Braintree, Chargify, Recurly and Saasy. If that’s too much work, just check out the two situations below, $5 and $50 subscription fees for up to 5000 subscribers. Stripe is the new low cost leader for small subscriptions, and is extremely competitive for larger ones. For $50 subscriptions, Chargify and Recurly are cheaper options, but not by much and they involve a lot more complexity because in both cases you bring your own merchant account and payment gateway.

Stripe also seems to meet all of my other requirements. You can use it to create a payment form that lives on your own site, which means the user experience is all within your control. And PCI compliance issues seem to be minimized because the credit card number never hits your server. As with Braintree and Saasy, you don’t need to worry about setting up your own payment gateway or merchant account.

This combination of price, functionality and simplicity seems too good to be true. My initial thought was that there must be a catch and I was smugly certain that I would find it as soon as I asked @stripe about data portability. But the answer was:

For sure! If you ever want to move to another provider, we’ll export your data for you.

I haven’t had a chance to use Stripe, so the catch might still be out there. And Stripe is a newcomer that doesn’t have the industry pedigree and experience of Braintree. But the service is interesting enough that I’m going to put the launch of our subscription offering on hold while I check it out.

–

Updated 1/20/2012: A few people pointed out that Recurly has updated their pricing and I have modified the calculator (though not the charts above).

See the discussion on Hacker News.

The Sparrow email client for the Mac is minimal, elegant and fast. It is designed from the ground up to work well with a gmail account, but it also supports IMAP in general. Many, many people I respect have been singing its praises. The only problem? It brings the compromise of a multi-line list view “back to the Mac”.

One thing that surprised me when I returned to the Mac in early 2010 was the vibrant market of native Mac apps. On Windows, the days of getting a thrill out of installing some neat little app had long gone, but on the Mac I felt like a kid again. Companies like Panic were crafting beautiful apps with fantastic attention to detail. And for the first time in years I started purchasing and using native apps that weren’t Office or Photoshop.

So when Sparrow was announced I jumped on the beta. When 1.1 with IMAP support hit the Mac App Store, I bought it. In terms of aesthetics it was love at fist sight. I loved the minimalism. I loved the design cues it takes from iOS apps. But as I used Sparrow it became more and more obvious that it just wasn’t going to work as my primary email client.

My problem is the inspiration that Sparrow draws from iOS apps. Not in general — in some respects the nod to iOS is delightful — but in one fundamental area where it really hurts usability. The main list view.

The iOS List View Compromise

Designing list views for a phone is very hard. You don’t have much width to play with and you need each item to be a decent sized hit target. So you can’t just implement a column-based list like the ones we’ve been using for years in filesystem browsers, email clients and a thousand other apps that needed to show a list of things with different fields. Instead, good phone UI makes a compromise and uses multiline list items like the ones you see in the iPhone email app or Twitter client.

Through clever visual design tricks, like different weighting, size and color for the text associated with different fields (from, subject, time, etc.), the multi-line list view becomes quite usable. But it is still definitely a compromise. The thing is that we don’t need to make this compromise on the Mac.

With reference to the screenshots of Sparrow and Mac Mail below, here are my top 3 gripes about the multi-line list (in priority order):

1. It is much harder to scan the list. No amount of visual trickery will make multi-line list elements, where each line has a different field, anywhere near as easy to scan as the single line list elements in a column-based list  view. Cognitive science will tell you that there is a whole different level of processing involved when you scan the Sparrow list as opposed to the Mac Mail list. If you put the two user interfaces side by side you should find that scanning the single line list feels fluid, almost like taking a snapshot. Scanning the Sparrow list, on the other hand, feels jerky as your brain pulls in slower, more sophisticated pattern recognition hardware to parse the list.
2. It is vertically inefficient. For the most part we use iPhones and iPads in portrait orientation, so optimizing for horizontal efficiency is essential. Macs, on the other hand, are almost exclusively landscape, so unless you use the list in a narrow window there will be a lot of wasted space between the people and title on the left and the thread information on the right. Although white space is a fantastic design element, this isn’t the good kind, because the information itself is still jammed into the left side of the list.
3. No re-ordering by field. Traditional column-based list views have a now-second-nature feature that is extremely useful. You can click the title of a column to reorder the list by that field. In Mail I often use this to delete a batch of email from one source, for example. I can’t find a way to do this re-ordering in Sparrow, probably because this feature is hard to do intuitively without column headings.

There are other niceties that come easily to the column-based view, like the ability to shift the columns around or to add and remove columns, but these are less important and are probably only missed by a small group of power users.

Lists Versus Streams

There are times when the multi-line list view will be good on the Mac. For the people who use their mail client in a very narrow window, for example. Or for people who see the large profile picture as a high priority. It also works quite well when you show a preview of the message content in the list view. Indeed, this is the way that Sparrow showcases their app.

In fact, used in this way, Sparrow is very similar to the Twitter Mac client, which I find to be very usable. And if most people prefer to browse their email much like they browse their tweets, then Sparrow is making exactly the right design decision.

So maybe what this really means is that we’re moving away from a list, and towards a stream, as the dominant view for a mail client. That people like me who view email as a list of items with subjects are dinosaurs.

I do love my Twitter client’s UI, for Twitter, and this got me thinking about why a list is more appropriate for mail than a stream. What it boils down to is that (for me) tweets and mail messages are very different things. Tweets are transient and optional. If I miss several hours of tweets, that’s ok. People don’t expect me to process every one of them. Things flow past me on the stream, I glance at some of them, react to a few, and most are never to be seen again.

Mail, on the other hand, is not optional. People who send me mail have the expectation that I will read it and respond to it. Sure, a lot of it is crap, but some of it is important, representing business or social opportunities that I wouldn’t want to miss. Email doesn’t flow past on the stream. It arrives in my inbox, and it stays there until I action it in some way. Sure, some of it gets lost there, but I’d prefer that not to happen.

Are we moving to a future where the expectations associated with mail get closer to those we have of tweets? In future, will I need to send DMs to ensure that people read an important email message?

Focus Group of Me

For me, that change isn’t going to happen soon. I see value in mail as a modality with higher fidelity and reliability than a stream of tweets. I have mocked up the mail app I would love to use. It is Sparrow in every respect, but for the main view, which I have replaced with a more traditional, column-based list view.

Most ideal would be a responsive design that changes the list type according to the width of the window. Or perhaps the option of picking either a list or a stream as the primary view. Maybe settings for both. I understand the need to minimize the number of settings, but this is such a fundamental aspect of the user experience that it probably justifies the additional, albeit hidden, complexity.

Then again, there are tons of smart people loving Sparrow just the way it is, and I don’t see any complaints about the main view in the Sparrow discussion group or elsewhere. So I do have this nagging feeling that I’m the only one who doesn’t get it. I’m sorry, Sparrow. It’s not you. It’s me. I’m a column-based list loving dinosaur.

IDC released Q1 global smartphone market share numbers yesterday. Here they are, with two additional columns that I think are useful.

The first column I’ve added just shows the absolute Q1 year-on-year unit growth so you don’t have to do the math in your head. The second shows these as a percentage of overall growth in units shipped. This is useful, because it shows that even when the smartphone market is viewed apart from other phones, Apple is the fastest growing vendor.

Another interesting perspective is the winners and losers.

IDC is very generous in their descriptions of Nokia and RIM, saying Nokia “may find itself in danger of ceding market share” and RIM “remained solidly in third place”. This seems blind to the share gains that the former two smartphone leaders are ceding to the rest of the field. The question is how far (Nokia) and fast (RIM) will they drop. At almost 60% of the market, their share offers a lot of easy wins for the ascenders before iPhone really starts competing head on with Android phones for market share.

I agree with Phillip Elmer-DeWitt that the speed of Nokia’s transition to Windows Phone will be crucial for them, but since there won’t be any new handsets based on the Microsoft alliance before 2012, it seems very likely that Apple will take the leadership position later in 2011.

Samsung is doing well and it will be interesting to see how they balance their “multiple operating system strategy”, particularly in light of the Microsoft-Nokia alliance. These new numbers and the recent suit/counter-suit do reinforce that they are currently Apple’s strongest competition.

Hats off to HTC, the plucky upstart in this group. They were early to the smartphone game and it is great to see that they are holding their own now that the market is going mainstream. They have shown with HTC Sense that they can differentiate the base Android OS in some interesting ways and if they manage to find a strong brand identity and awareness, they might even find themselves in the final 5.

Evidence that this market is far from baked: “Others” is large and growing fast. I would love to see a more detailed breakdown of what’s happening down there.

I’ve done the MBA thing, I’ve worked in the strategy team of a large software company and I’ve done my share of theorizing and plotting and moving the pieces around the big war chart. So I’m aware of strategery and moats and network effects.

That sort of analysis is interesting and worthwhile, but sometimes when people get into a world of two-by-twos and Porter’s 5 forces and blue ocean red ocean, they lose sight of the real world. The world where real people with real problems walk into real stores and buy real things. In the real world today, Apple is killing it. Look at any metric comparing Apple to other handset manufacturers. ANY METRIC. It will tell the same story. Their handsets are in higher demand than any other manufacturer, so they can charge more than anyone else. And their cost basis is lower because they are selling more identical units with shared components than any other vendor. As a result they are the fastest growing major handset vendor and in a few short years they have gone from not being at the table to eating half of the profits in the whole phone market.

Of course, the converse is also true. If you only look at what consumers are doing with their hard earned dollars today, then you’ll miss the macro changes in the market that are leading indicators of what might happen tomorrow. In the case of phones, the macro issue getting the most attention is the platform war. We have learned from the PC industry that platform network effects are extremely important. While it is dumb to assume that exactly the same dynamics will apply to phones, it would be insane to ignore the possibility that they will will manifest themselves, albeit in a different way.

There are many ways to argue against the platform thesis. First of all, the players are different. Apple 2011 and Google 2011 are not Microsoft 1995 and Apple 1995. Second, the product is different. Mobile has a different set of user experience and technology requirements. Third, the context is different. The biggest factor here might be that during the PC/Mac platform war the web was nascent. Finally, this is a movie we’ve all seen before. Surely handset vendors will see that an Android future leads to the inevitable commoditization of their part of the value chain?

But even with all the rational arguments against it, one has to acknowledge that there are parallels and given that network effects are so extremely powerful, they are parallels worth thinking about. If Android phones and apps get good enough — not necessarily better than iPhones and iOS apps, just good enough — and the real Android application footprint¹ passes a certain tipping point in the market, it might be all over for a decade or more. This, I think, is what Fred Wilson and Bill Gurley are seeing… the horizontal tipping point.

My implicit assumption is that there will be a tipping point. Right now there are really two industry architectures co-existing in the smartphone market, which is inherently unstable. I think it is likely that at some point the market will move to a more stable equilibrium where either the horizontal or vertical architecture is clearly dominant. If this is true, then the interesting questions are around the race to the tipping point. What are the conditions that support each tipping point? How close are we to either one?

The Horizontal Industry Tipping Point

I think most people would agree that the horizontal tipping point is all about apps. Android needs to enter the virtuous cycle where developers go there first because it represents a bigger opportunity, and consumers go there first expecting to find more of the apps they want.

Of course, the phones are also important, and real competitors to the iPhone² would definitely help to kick start the virtuous cycle. By “real competitor” I mean one with an identifiable line of products that have coherent messaging and are selling in volumes that are at least in the same order of magnitude as the iPhone, and whose profits allow sufficient reinvestment to make the product line a sustainable investment. Developers would be excited by them and you would see people using them in the subway.

This doesn’t exist for Android today. Verizon is cobbling together a product line by putting a single brand, Droid, on handsets from different manufacturers. HTC is making a valiant effort to create a branded user experience with HTC Sense. Motorola may follow Xoom with more products and create a credible product line. But it doesn’t exist yet. Today, we make comparisons between one handset manufacturer, Apple, with everyone who makes Android phones (40-100 different devices). That is telling.

While great iPhone-killing Android phones would help to push the industry past the horizontal tipping point, the real pre-requisite is apps. There need to be killer app experiences that are uniquely available on Android. I say “App experiences” and not simply “Apps”, because even if the killer apps were just significantly better on Android this might be enough.

So the crucial question becomes, how much bigger does the (real) Android application footprint need to be before most developers pick Android first, and regard iOS to be optional?

Of course it is hard to be specific, but given the factors in favor of Apple, the answer is somewhere in the region of “a LOT bigger”. With a manicured product line and just a few distinct models, Apple will always be a much more uniform platform footprint. It also has a significant lead today — a much more vibrant app economy and a larger selection of apps. So with an equally sized app footprint, Android isn’t close to big enough to tip the developers in their direction. At double the size? Maybe.

The important points are that (1) in order to win a platform war, Android has to turn out to be the best place to target and find apps. To date, this has not been its strength. And (2) app platform needs be a factor that can generate significant demand side economies of scale. The latter was true for PCs, but we can’t assume that it will be true for mobile.

The Vertical Industry Tipping Point

PC history has proven that one stable industry architecture (where stability is measured over a decade or more) is a horizontal software platform with multiple hardware vendors. And that might happen with Android. This is where a lot of analysts stop. The success of this model in PCs was so overwhelming that for them it is just a question of when, rather than if, we will reach the horizontal tipping point.

But there are other ways this industry could go.

Apple’s dominance in digital media players is one example, where a single vertical player gets 70-80% of the market and by smart reinvestment of their profits and even smarter exploitation of their supply chain economy of scale advantage (e.g. cornering the market on 1.8″ hard drives, and later flash memory) stays dominant. The only thing that removed iPod from this dominance was a disruption — phones (or more accurately, the iPhone) entering the media player market as a substitute.

Was iPod a consumer electronics dress rehearsal for iPhone? Can Apple reproduce iPod like dominance in the phone market? I argued no for years. Now I see them exercising the same supply chain muscle in the phone market and I’m not as sure of myself. It still seems unlikely given the sheer size and reach of the market, but then again, I would have argued apriori that the current success of the iPhone, documented so well by Horace Dediu, was impossible too.

Still, the more likely outcome in a dominantly vertical industry is several big competitors, each with a different platform. For example, a future where Apple-iOS competes with Nokia-Windows, Samsung-Android and HP-WebOS. In this future there is healthy competition between these major players, but buying a phone is like buying a car. There are well known brands with clear positioning and loyalties, and people with brand affinity know when the new models are coming out.

Where the horizontal industry tipping point was about the network effects associated with apps (aka demand side economies of scale) the vertical industry tipping point is about supply side economies of scale. It is about the effect of relative market share on handset vendor economics.

Here’s how it works. As we get closer to the vertical industry, the increasing share being grabbed by an ever smaller group of manufacturers allows them to exercise economies of scale. Specifically:

1. Marketing economies of scale: Successful handset manufacturers can use a lower overall marketing budget but still spend more on marketing per distinct product line. You see this effect today. Compare Microsoft’s massive, but thinly spread Windows Phone marketing budget and Apple’s laser-focused iPhone marketing budget. Ask 10 people whether they have seen a WP7 ad and then ask them if they have seen an iPhone ad.
2. Manufacturing economies of scale: The more components a handset manufacturer can buy, the better the deal they can drive with the component supplier. This effect is incredibly important, and seldom discussed. Analysts can’t get a hold of it because these deals are closely guarded secrets by suppliers and buyers alike. Some manufacturers will drive enough demand for certain components to take them in-house (e.g. the A5 SoC), further reducing their costs and dependence on suppliers.

The simplest distillation of the success of a strategy is consumer Willingness-to-Pay ($) minus production Cost ($) relative to your competitors. As the industry moves towards the vertical tipping point a few players are increasing the former and decreasing the latter and accelerating away from the rest of the pack. At some point, big companies without these economies of scale just aren’t be able to compete and wither out of the market.

Apple: Speed Limited

Apple is showing signs of marketing and manufacturing economies of scale today. There is something holding them up, but contrary to the popular narrative, it isn’t Android. It is their own ability to scale fast enough to meet market demand.

There is scale in manufacturing, where they have done a remarkable job of going from a company that shipped zero phones to a company that today ships tens of millions of phones and tablets. Still, they are probably scaling production just about as fast as they possibly can. Then there is scale in distribution, which is mostly about getting into the assortment of as many mobile network operators as possible.

In both of these areas their major competitors, Samsung, Motorola, RIM, Nokia, had a massive head start. And none of the phones that compete with iPhone today ship in sufficient volume to even make a supply chain blink or generate sufficient demand to test the reach of a distribution channel. So a flood of products of all shapes and sizes, made more credible by their Android label, is scooping up the smartphone demand that Apple, with its production and distribution limitations, can’t meet.

The crucial question for the vertical industry tipping point is how fast can Apple scale their manufacturing and their distribution. And can they scale fast enough to dominate this massive market? As with the horizontal tipping point, this is impossible to accurately quantify, but I think the fact that Apple is losing ground against Android is a sign that they can’t scale fast enough to achieve an iPod-like dominance of the phone market.

This makes it important to distinguish between two different vertical industry outcomes: iOS dominance and iPhone leadership.

So I think there are three potential outcomes in the mobile handset industry that are worth contemplating:

1. Android dominance implies a future where the industry is horizontal, with an OS vendor creating a dominant application platform with its associated network effects (demand side economies of scale).
2. iOS dominance implies a future where Apple enjoys the demand side economies of scale associated with a dominant application platform, and the supply side economies of scale associated with being the leading handset manufacturer.
3. iPhone leadership implies a future where the dominant player is a vertically integrated handset manufacturer that enjoys supply side economies of scale in manufacturing and marketing.

The App Platform Isn’t What it Used to Be

The striking thing about the three scenarios above is that the first two, the most popular two, are based on the fundamental assumption that app platform network effects will be a significant factor in determining the outcome. But will they?

One big wildcard is the extent to which cross-platform web-based experiences reduce the ability of a native app platform to create meaningful network effects. This is the huge difference between the PC world of the late ’80s and the phone world of 2011. Native apps may continue to be significant, but the existence of the web makes them less significant than apps were back in the day.

This isn’t an argument that all apps will be web apps. Regardless of whether the client is a native app or web based, these days a lot of the important computing is on a server somewhere, and not on the local client. The “app” is most often little more than a presentation layer. Native client-side apps are better because they react faster, handle offline situations better and have more tailored user experiences than their web based counterparts. Most of them are in a sense just custom browsers for a specific web service.

The other difference between the ’80s and today is the massive advances that have happened in development technologies. Single developers are churning out sophisticated apps and doing so for multiple platforms. Even if native apps reign supreme, it really isn’t clear that developers will face agonizing decisions about whether to do iOS or Android. They’ll just do both!

What this means is that the first two of my three scenarios are probably built on something that won’t exist: A platform with sufficiently strong demand side economies of scale that this determines the market outcome.

The New Platform Network Effects

Ironically, Apple is to blame for this recent obsession with app platform network effects. Just a few years ago the vast majority of people were so past native apps and everyone was looking for the new dominant platform in the cloud, but the success of their iOS AppStore has sucked our thinking all the way back to 1995 (incidentally, a place much more comfortable for many analysts than 2011).

And it is still possible that an Internet based service plays the role in mobile that native apps did for PCs in the 90’s. In some respects, iTunes is doing this today. The service is unique to iOS based handheld devices, and if a social service like Ping actually worked, it could generate a powerful network effect.

But that’s overlooking the biggest single network effect since the PC app: Search. In the search space, Google is killing it. Their search product is an oil gusher of advertising revenue, where Microsoft, with a very similar product, is hemorrhaging money. Why? Demand side economies of scale. More people use Google search, so Google can deliver more relevant search results, so more people use Google search.

If Google could take this network effect and apply it to Android, that would change the game. Many things conspire to make this improbable though. For one, regulatory agencies saw Windows happen, and they aren’t keen on that kind of de-facto monopoly repeating itself. But even putting regulation aside, it would be a huge gamble for Google to forego the traffic from a marget segment as large as the one iOS represents today.

Could Google achieve a network effect through another bundle of services that work best on Android? Possibly, but they haven’t shown this sort of success with obvious network effect candidates, like the social graph. They are still first and foremost (and only?) a search and advertising company.

And while the social graphs of Facebook and Twitter have powerful network effects, they are not currently tied to any one device OS platform.

The Outcome: A Very Ordinary Industry Architecture

So far it looks unlikely that the next generation of computing devices will have an industry governed by demand side economies of scale. Supply side economies of scale, on the other hand, are very much alive and well. Component costs, and even access to component supply, will continue to be a crucial differentiating factor for manufacturers. With more noise bombarding consumers every day, marketing economies of scale will also continue to be important.

It follows that the two outcomes that define the popular Android versus iOS narrative are much less likely than a concentrated and effectively vertical industry with several strong competitors. Even if some of these competitors share an OS, this OS will not be dominant in the sense that Windows is dominant in the PC industry today. App platform network effects will influence the industry, making for fewer competitors than in a market like TVs or toasters. But they won’t define it.

The extent of Apple leadership will not be determined by the success of Android. Rather, it will be limited by Apple’s own ability to scale manufacturing and distribution. These limitations might allow other manufacturers (and potentially close partnerships like Microsoft-Nokia) to regain share and grow faster than Apple for a period of time. No doubt myopic analysts will again take this as a sign that Apple is “dead in the water”, but in the end it is highly likely that the industry will stabilize with the company in a convincing leadership position.

But only until that equilibrium is disrupted.

—

1. Given Android’s fragmentation it is important to make a distinction between the real app platform footprint and just the number of Android phones. Analysts jump to lazy conclusions using the number of Android phones shipped as a proxy for the application footprint, but it isn’t reasonable to do this (yet).
2. In this piece I’m using “iPhone” as shorthand for the family of handheld devices that Apple bases on iOS, to distinguish it from iOS the application platform.

In a future where every 3rd party thing you do on your phone is done using some sort of web-based UI, phones are only differentiated by (in no particular order):

1. Industrial design
2. Battery life
3. Performance of web apps on the device
4. Quality of UX for essential built in functions (e.g. voice calling)
5. Price

That is, no app platform differentiation. No virtuous cycle where developers target the platform with the most users and consumers choose the platform with the most apps. Imagine the PC/Mac industry today without Windows dominance and you might not be far off.

Put differently, in a future of pure web app domination, the handset OS is irrelevant and there is no horizontal platform for Android (or any other OS) to win.

So I find it interesting that some people are both web app proponents and bet on Android having some sort of meaningful dominance at iPhone’s expense. To me these are contradictory points of view. I imagine their belief is based on some combination of the following factors.

Google is such a visible defender of openness and the web. This is misleading though, because for their core technology (search algorithm) they are even more closed than Apple, as they should be. In the case of mobile specifically, the openness is essential to convince OEMs that Android is not a re-run of the DOS/Windows platform dominance movie. In fact, Google’s support of the open web might be in direct contradiction with Android’s long term dominance, but they might not care. Web platform dominance and the continued relevance of web search and advertising, Android or no Android, is the higher order bit.

Much of Apple’s current success is driven by the App Store and the virtuous cycle it creates for iOS. The mistake here is to believe that Apple falls when the App Store’s relevance goes away. Even if it were to happen and iOS apps became less of a differentiator, the same would will also be true for the apps on every other mobile OS. Meanwhile, the initial boost that the App Store provides in its heyday will position Apple far ahead of every other handset manufacturer in a game that will increasingly center around marketing and manufacturing economies of scale.

Disruption normally ousts the incumbent. But not always. The iPod is currently being ousted as the dominant digital media player… by Apple’s own iPhone. It is remarkable how aggressively they disrupted their own product line and shifted their revenue mix from media players to phones.

A belief that low cost phones that access the web will undercut Apple’s premium iPhone. There is a fundamentally flawed implicit assumption that other manufacturers (even small ones) will somehow be able to build phones at a lower cost than Apple can. From a cost point of view, consumer electronics is a scale game. Given its footprint, Apple will negotiate significantly lower prices on components. It might even buy up so much supply that other manufacturers will be starved (something they did with the iPod). Their buying power is enhanced by the fact that they share at the very least supplier relationships, and sometimes even actual components, across their iPhone, iPod, Mac and Apple TV product lines. And if that weren’t enough, Apple develops key components like the A5 SoC in-house.

Apple is not vulnerable to low cost competitors, it is the lowest cost competitor in the categories it serves. It isn’t the lowest price competitor, but the only thing stopping Apple from shipping a lower priced iPhone is that they don’t need to. It would cannibalize their existing line and reduce their profit margins at a time when there is no credible low price alternative. But when the time comes, their past actions suggest that they won’t hesitate to launch downmarket offerings.

The bottom line is that a web-only world changes Apple’s strategic options, but it doesn’t kill the iPhone. What’s more, it’s a world where handset vendors are relevant and OS vendors are not. And where it would be harder for an OEM to hide a sub-standard product behind an OS platform brand like Android.

If you had to bet today on a handset manufacturer that could lead this kind of market based on the five potential areas of differentiation I listed above, who would it be?

I think Andy Rubin’s team are doing an amazing job. As OS platforms go, Android is a great product and adoption among OEMs is phenomenal. But I think that people are missing the point of Android and its importance to Google. Even if Android doesn’t exist 10 years from now, it will still have been a fantastic success¹. Google staved off complete iPhone dominance by propping up a bunch of software-incapable OEMs with a good OS and a great web browser, and they accelerated the progress of web standards on mobile. They have probably shortened the time-span that Apple can milk the App Store, a model of distributing content that is completely untouchable by Google’s traditional search and advertising machines².

Personally, I think the future is going to be more complicated and more interesting than web wins or native wins. But If you do believe that the web will dominate and that native apps will decline, then you must also accept that standalone operating systems, while serving the purpose of positioning the handset manufacturers in the near term, will be near commodities in the longer term.

—

1. In the language of the value chain (the set of vendors that together deliver a user experience in the simplistic mobile value chain above): Google and Apple are not direct competitors in their core businesses (Google doesn’t build devices and Apple doesn’t have a search engine), but they are competitors for profits in the value chain. One simple rule of thumb is that the piece of the value chain that has the least competition grabs the most profit. Good examples are Microsoft’s success with Windows in the PC value chain, and Google’s success with search on the Internet (in stark contrast to the fortunes of PC OEMs in either value chain). They dominate their respective pieces of the value chain. Apple dominating the phone handset is a fundamental threat to Google’s position in the mobile value chain (where Google search and advertising is less established). Android is one way they can neutralize this threat. Their goal is not so much to take away Apple’s business as it is to loosen Apple’s hold and allow more of the value to flow to Google’s core business.
2. Android will have other effects too. For example, their Android dependency is stopping OEMs like Samsung and Motorola from developing true internal software capabilities, or at least slowing their internal efforts down. So if and when HP and the Nokia/Microsoft partnership get their acts together, it will be that much easier to scoop up the piece of the market that Apple doesn’t already own.

This analysis by Henry Blodget on Business Insider makes the classic (repeated ad-nauseum) mistake of putting Apple in a race they’re not in. Apple does not make a third party OS platform for phones. It makes phones and it makes an application platform for developers. What he is implicitly doing is using OS footprint as a proxy for app platform footprint, and at this point in the mobile market’s evolution, that is just wrong headed.

First of all, it distorts the reality of what’s happening in the handset market. Blodget makes a lot of Android versus iOS growth, but taking the Comscore numbers that he uses, look at the growth in the top OEMs over the last quarter. Among Apple’s phone competitors in the top 5 OEMs (by share of mobile subscribers), only Samsung shows positive growth. And that is one third of Apple’s growth.

Now, Blodget shows the growth in share points, but the difference between the OEMs is much more stark if one looks at percentage growth. Apple’s share grew almost 14% (from 6.6% to 7.5%) whereas Samsung, the fastest growing of the top Android OEMs, grew only 1% (from 24.5% to 24.8%). The take away from this is that of the top OEMs, only Apple is growing faster than the overall handset market in the US.

Blodget doesn’t focus here though. How could he? His headline says “iPhone [is] dead in [the] water”. Instead he focuses on OS share. He shows Android’s share of the OS market increasing 27% (from 26% to 33%) and the iOS share increasing 1% (from 25% to 25.2%). So the number of phones running Android is increasing a lot faster than the number of phones running iOS.

All of this does beg the question, where is the Android growth coming from? I think it is useful to think about the growth in terms of two components.

1. The top OEMs, Samsung, LG and Motorola, as their internal mix shifts away from other platforms to Android. Comscore’s data says that 30% of mobile users are on smartphones, which means that Android’s 7 points of growth over the last 3 months corresponds to about 2 points of growth relative to phones overall. As OEMs double down on Android, they are replacing Windows Mobile and Symbian phones with Android phones, and high end feature phones with Android phones. Brand loyal customers will switch along with them. Are these customers all hungrily after a fantastic app platform? No, a lot of them are just getting their next phone.
2. The rest: OEMs that aren’t in the top 5. Up and comers like HTC and lots of other smaller OEMs. When I looked at the Android market last November, there were roughly 80 phones in market and that number had doubled year on year. I’m pretty sure that the number is a lot higher today. I theorize that the smartphone market is growing way faster than Apple can handle (without compromising their quality/service bar) and a proliferation of Android phones are finding their way into the hands of new-to-smartphone users. People who don’t want to let go of the physical keyboard, or want a slightly smaller or larger screen, or who take advantage of one of the free phone of BOGO offers that are often available for low end Android phones, or who can’t get an iPhone on their mobile network operator.

In both of these situations, even the most die-hard Android supporter would have to admit that the quality of the growth, measured by the customer’s intent to exploit the benefits of their phone and make full use of it as an app platform, is vastly different between Android and iOS. Every new iPhone user knows what they’re buying into. Many Android users have no idea that their phones even run apps.

Blodget doesn’t mention anything like this. He mentions the OEM share in passing, and then locks on to one simple number: The OS footprint. It is a simple number, and it supports his narrative.

Here’s the thing though: OS footprint comparisons are irrelevant from an application footprint point of view if people with new Android phones can’t or don’t embrace apps on their phones. The only place it matters is in articles like the one Blodget wrote. If anything, this explosion of Android devices will have a negative impact on the chances of Android having an app ecosystem as exciting as the one around iOS. Every new Android model makes it harder for Google to control this monster of an ecosystem that they have created and ensure a consistently good user experience across handset models.

So while it is completely valid to compare the footprint of two different application platforms, comparing Android’s fragmented story with iPhone’s ordered iOS platform is either intentionally misleading or completely ignorant. It implies that all else is equal, when clearly this isn’t the case. As an application platform, Android has a long way to go.

There are valid ways to measure the progress of an application platform and they involve (surprise!) the apps. Where are most of the new apps appearing? Where are developers making the most money? Which platform’s users are using more apps? By any of these measures the iPhone is leaving other app platforms behind.

But what of the trend? Isn’t Android on a path to rectify this situation and become a competitive app platform? Yes, things will probably improve. But its not exactly plain sailing. Samsung is hedging its bets with Windows Phone 7, and Motorola is building its own OS capability. Neither of these strategies are likely to do them much good, but the point is that they have anything but razor sharp focus on making the best Android-based phones the world has ever seen.

Here’s the best evidence that platform fragmentation is an issue and general quality of Android-based phones is lacking: Google’s recent actions to clamp down on the ecosystem. I’m not in the camp that believes this was an intentional bait and switch by Google. I think they started out with the goal of being open, but they are learning that this approach doesn’t work in the world of phones where tight tolerances on user experience require much more coordination between hardware and software.

I wish that analysts like Blodget would look at this market from the point of view of the things consumers care about and make decisions about. Phones and apps. I’m not even arguing that iOS will beat Android in the long term, I’m just appealing to analysts: Please, lift your game. Go beyond grabbing the simplest number you can find and using it as the basis for useless, potentially misleading conclusions.

I’ve spent some time investigating billing solutions for a premium subscription feature we are considering for YLF. This area is a minefield. Until recently, it has been a lot of work to get an online business set up with recurring billing. Over the last year or so several startups identified this pain and set out to offer easy solutions. So today there are several ways that on the face of it seem to be simple.

Unfortunately, the minefield is still there.

In this post I’m going to summarize what I learned about four of the services that promise to take the pain and complexity out of online billing for startups. They are Braintree, Chargify, Recurly and SaaSy. Note that I haven’t implemented any of these solutions.

When I first started thinking about recurring billing my focus was on finding a solution that would minimize the amount of custom code that I would have to write. Like most startups, I’d like to spend more time on product and user experience, and less time on infrastructure. This is the area where my four options all excel. Obviously there are differences that will impact the user experience (more on that below), but all of them eliminate a lot of the pain associated with building the system yourself.

Payment Processing Setup

The second kind of setup pain, which I will call payment processing setup, is the one you don’t expect. It is the insanely complex world of payment gateways and merchant accounts. I won’t go into details, but suffice it to say that (1) the payment processing world is still catching up with Web 2.0 and (2) the risk associated with processing credit card transactions has added layers of complexity. In the past the best thing to do would be to find someone you trust who has waded through this mess before and get them to help you. If you don’t have a friend like this, Sachin Agarwal’s great outline of the payments space is an excellent place to start.

Happily, Braintree and SaaSy eliminate the need to set up your own payment gateway and merchant account. Chargify and Recurly don’t address this directly, and although they do promise to help you get started, this means that they aren’t really offering a complete payments solution. At least not in the way I would define it. All of the engineering is done, but some of the business/logistical complexity is left to you.

One thing worth mentioning is that merchant accounts are particularly tricky, but companies like FeeFighters have identified this and created services that make it easy to compare merchant account offerings.

Customer Data Portability

This might be the most critical aspect of your payments system: the ability to leave the provider and take your customers’ credit card data with you. It is frighteningly easy to get yourself into the situation where a provider won’t, or can’t, release it to you. This not only impacts your ability to change providers, but can hurt you in other situations too. Just read the nightmare scenario described by Isaac Hall, founder of Recurly, where a company he worked for previously lost all their customer data.

Also see CEO of Braintree, Bryan Johnson’s open letter to PayPal and Authorize.net on this issue.

While Recurly and Braintree have their own “vault” for customer data and promise full credit card portability, Chargify and Saasy do not. If you use Chargify, you need to set up your payment gateway to store the customer data (e.g. Authorize.net’s Customer Information Manager option), so they don’t have control of the data and couldn’t release it to you even if they wanted to. Ken White of SaaSy told me that the credit card data portability standard is something they don’t support yet, but will consider in future.

Personally, I’m torn on this issue. On the one hand my intuition tells me that the portability is critical, and this is reinforced by the horror stories told by those who support it. On the other hand, many, probably most, successful businesses are operating without it.

Cost Transparency and Predictability

Here’s another area where complexity quickly gets the better of you. All of the services have different price structures, so this isn’t just a case of building a simple spreadsheet. In fact, I wrote a script to do the calculations and I’ll get to that in a moment. First, cost transparency and predictability.

Braintree and SaaSy are the most transparent, predictable options, but for different reasons. SaaSy is without doubt the simplest recurring billing payments solution the world has ever seen. You have two options: (1) 5.9% plus 95c per transaction, or 8.9% per transaction. That’s it. You don’t even pay additional fees for chargebacks (when someone disputes the charge on their credit card).

Braintree is transparent and predictable, but they expose you to more of the complexity inherent in the system. There is also a little more risk in their pricing because there is an added cost for chargebacks.

Chargify and Recurly are much more difficult to parse from a cost perspective, simply because they are only one component of the cost. You pay separately for your payment gateway and merchant account. This means that calculating your overall costs becomes a matter of getting quotes from three different places and building this into your model. I must say, their pricing is really quite misleading when you are new to the payments space. Of course, you understand the realities of the additional costs of the gateway and merchant account soon enough, but I wish they were more upfront about it on their pricing pages.

No doubt there will be many people who have had great success using Recurly or Chargify and no problem at all getting set up with payment gateways and merchant accounts that have reasonable fees. But here’s the thing: You can go to the Saasy or Braintree pricing pages and immediately know what the costs will be. For Chargify and Recurly, it will be their fees, plus something else. And for that something else, your mileage may vary.

Cost Comparisons

Ok, the bottom line. I’ve looked at many permutations of this using my cost calculation script. Here are my takeaways.

First, you pay for easy, low risk and predictable. In most situations SaaSy is significantly more expensive than the other options.

SaaSy’s model can make it lower cost for the first few subscribers. This is especially apparent for low subscription costs, where SaaSy is profitable immediately, whereas the other options all have fixed costs. For most purposes this is not material though — if you don’t have the subscription fee or the number of subscribers to quickly get past the break even point then you have bigger problems. Psychologically though, there is something very appealing about SaaSy’s $0 price of entry.

For larger subscription fees, you pay dearly for the simplicity of SaaSy. For a $50 sub, for example, the other three options tend towards 3.5% fee per transaction overall, whereas SaaSy is pegged at 8%+ for both pricing options.

Despite offering a lot more value than Chargify and Recurly, Braintree is competitive with a around 0.5% premium in most situations. You mileage may vary, but for a solution that shields me from the payment gateway and merchant account complexity, this is cheap at the price. Also, it is quite possible that unexpected costs in the payment gateway and merchant account will eat up that difference and more if you use Chargify or Recurly.

One other thing. Chargify and Recurly only quote pricing up to 10,000 transactions. In our monthly subscription situation that translates to 10,000 subscribers. Many startups probably have ambitions north of 10,000 users, but I think it is safe to assume that their pricing will get better beyond 10,000. Braintree and SaaSy are also likely to be open to negotiating the pricing structure once you get beyond 10,000.

But don’t take my word for it — play with the numbers yourself.

User Experience

Here I’m on shaky ground because I haven’t (yet) created a billing experience based on any of these solutions, but the main impact I see is the extent to which you can integrate the sign up experience into your site, securely. The “securely” part is very important. It means that I want to minimize PCI compliance hassles and have therefore decided that the credit card number should never be stored in our environment.

Braintree is the best of all worlds in this respect. The signup form is on your site and totally within your control (no iframes), but their transparent redirect means the credit card number never touches your server.

SaaSy will host a sign up page, so it isn’t on your site. but they do allow you to style this page with your own CSS.

Chargify and Recurly will host your sign-up page and they have templates that can be customized. Just as secure as Braintree or Saasy, but with less control over the user experience. Note that you do have the option to use their APIs to completely control the experience, but then you will be storing the credit card data on your server at some point.

Decisions, Decisions

All of these solutions do a great job of eliminating pain. Recurly and Chargify focus on the aspect of building the system and make that orders of magnitude easier than it would be to do so yourself. Braintree takes it a step further, and at relatively low cost, also removes the complexity and risk associated with payment gateways and merchant accounts. SaaSy goes all the way, making it easier than it has ever been to set up recurring billing.

Braintree and SaaSy also give me more control over the user experience, which is important.

SaaSy is new though, whereas Braintree is a tried and testing solution that is used by many well known services (e.g. OpenTable, GitHub, EngineYard, 37signals). And unless your monthly subscription fee is low, SaaSy is very expensive.

Braintree has one thing that is really compelling: complete customer portability. Ultimately this might be the deciding factor.

For you, here are the questions I think are important and the way these solutions stack up against them:

Factor	Solutions
I don’t want to think about payment gateways and merchant accounts	SaaSy, Braintree
I need very low costs at the start (< 100 subscribers)	SaaSy
I want the absolute lowest cost after getting off the ground (1,000 to 10,000 subscribers)	Recurly, Chargify
I want complete control of the user experience without any sacrifice in security	Braintree
I need customer data portability	Recurly, Braintree

Teach Me

If you know more than me about recurring billing (likely!), then please weigh in and make corrections or additions. If you are a provider (one of the ones I mention, or another one) feel free to jump in too. I’m particularly interested in the issues around customer data portability. I feel like I’m missing some important pieces of that argument.

I expect to make changes to this post as my understanding of the space evolves.

Update 10/2/2011: Stripe, a new online payments service, launched recently and I wrote a new post to add them to the comparison. It is a significant update. Assuming they are true to their word on features and data portability, they win on all counts in a comparison table like the one above.

Update: Thanks to @ctide for pointing out one serious bug in my first version of the script that calculated the costs for Saasy. I neglected their $0.75 fee minimum per order. This led me to believe that Saasy was very competitive for smaller subscriptions, but they aren’t. I have corrected the script and updated the text to reflect this.