I’m : a programmer, writer, podcaster, geek, and coffee enthusiast.

Tesla’s new non-lease option

Tesla announced a “new finance product” that’s an interesting hybrid of buying and leasing. Supposedly, you buy the car with favorable financing terms, but with a minimal down payment (after tax subsidies) and a buyback option at a fixed residual after 36 months. It sounds like the tax benefits and flexibility of owning, but the predetermined resale benefit of a lease.

I wish Tesla would stop playing fast and loose with the numbers, though:

When considering the savings from using electricity instead of gasoline, depreciation benefits and other factors, the true net out of pocket cost to own a mid-range Model S drops to less than $500 per month.

What does “true net out of pocket cost” mean?

The middle Model S, by Tesla’s own calculator, will require you to pay at least $7,990 as a down payment — probably more — before you get any tax credits.1 Even ignoring the significant up-front costs, their calculator is quoting a $711/month “total cost of ownership”, which is actually a $1,252/month car payment on a 5-year loan.

That’s pretty far from “less than $500 per month”, so let’s give them the benefit of the doubt and assume that by “mid-range Model S”, they really meant “the cheapest Model S with zero options”. That brings the actual payment to $1,097/month (again, hand-waving away the substantial up-front costs), or a $471/month “effective cost”. This is probably the figure that Tesla based this claim on.

But that price is also based on a number of extremely optimistic assumptions:

So if you live in most states, don’t deduct your vehicle as a business expense (most people’s vehicles don’t qualify), and would otherwise buy a 5-series, your “effective cost” by Tesla’s calculator rises to a minimum of $906/month — and that’s for their cheapest model with no options, assuming that a surprise rich benefactor comes out of the woodwork to pay all of your sales tax and the remaining up-front costs after tax credits.

Tossing around that “less than $500 per month” figure to the press and the public is dishonest at best.

  1. The middle model, 85 kWh but not “Performance”, starts at $79,900 MSRP with no options added (unlikely) before a $7,500 U.S. federal tax credit. The 10% down payment required by the bank needs to be based on the full, pre-tax-credit sale price since that’s what the bank is paying, so the down payment for a “mid-range Model S” is at least $7,990 plus sales tax (unless tax is rolled into the financed amount, in which case the monthly payments will be noticeably higher). Average U.S. sales tax seems to be about 7%, which would put the down payment at $13,583. ↩︎

iPhone 6

Ken Segall’s iPhone Naming: When Simple Gets Complicated argues for the next iPhone to be named “iPhone 6” rather than “iPhone 5S”:

More important, tacking an S onto the existing model number sends a rather weak message. It says that this is our “off-year” product, with only modest improvements. If holding off on the big number change achieved some great result, I might think otherwise. But look what happened with iPhone 5.

This model brought major changes: bigger screen, better camera, greater speed, all on a thinner and lighter body. Yet its improvements were still dismissed by many as “incremental.”

I agree: if Apple’s going to keep using sequential numbers (rather than feature-based names, like the second iPhone being named “iPhone 3G”), they should just give every model the next number. The next iPhone should either be the iPhone 6 or the iPhone Something Else, not the iPhone 5S.1

The iPhone 4S was a huge improvement over the iPhone 4, but the press and fans shat all over it because it had the same case design and therefore wasn’t “an iPhone 5”.

The 4S shipped during the clear beginning of the current era of Apple pessimism. Apple reduced people’s expectations with the “4S” name at the worst possible time: just as many were starting to think iPhone innovation was slowing, Apple named the new iPhone in a way that suggested, “This isn’t a big improvement.”

It’s a move that they could have made when they were on top of the world, PR-momentum-wise, much like when they released the iPhone 3GS, a similarly substantial improvement over the iPhone 3G that was similarly underrated by the public. But when the 4S was released, Apple no longer had that much positive momentum.2

A year later, when Apple did release a model named “iPhone 5” that was far better than the 4S and had an external redesign, the inertia of Apple pessimism was so strong and the press had become such petulant children about Apple products that they shat all over it even though it was a huge update that gave them everything they asked for, plus more.

Now, Apple pessimism is even stronger. No matter what they release and no matter how well it sells, they won’t win over the press, the pundits, the stock market, or the rhetoric. Not this year. They could release a revolutionary 60-inch 4K TV for $99 with built-in nanobots to assemble and dispense free smartwatches, and people would complain that it should cost $49 and the nanobots aren’t open enough.

Since they’re not going to meaningfully improve their PR momentum anytime soon, they might as well at least avoid trying to make it worse. This is not the time for Apple itself to suggest to the world that it’s slowing down innovation on its most important product.

Regardless of how big of an improvement the next iPhone is, Apple should just call it the iPhone 6 and give the finger to anyone who questions whether the name fits.

  1. Plus, since the “5” and “S” characters are so similar, a “5S” model would be more awkward than usual. ↩︎

  2. To make matters worse, they heavily focused the iPhone 4S’ marketing on Siri, a feature labeled “beta” that not only lived up to that label, but is fundamentally disappointing to most people’s expectations even when it works reliably. ↩︎

The market for paid iOS apps isn’t dead

I’ve seen lots of discussion about the paid-app market recently, but most of what I’ve read hasn’t sat quite right with me.

Lex Friedman’s piece tries to persuade customers to pay more, which is a nice sentiment, but it won’t achieve meaningful change. Nobody can yell loudly enough at enough people to change the app market’s pricing expectations and behavior. The market is far bigger than any of our audiences.

Chris Adamson argues that there’s effectively no market for paid apps, and most iOS-developer income comes from contract work:

Earth to MacWorld: It’s already too late. The market has spoken, and it refuses to pay for apps, even when the toxic side-effects of that are manifest. …

Of all the full-time iOS developers I know, almost none of them work primarily in writing apps for sale to end-users. Nearly all of them, myself included, work for clients for whom an app makes sense in some other business model.

Certainly, it’s easier to make a living working for other people than trying to make your own product. But that has always been true in the iOS market, and in fact, it’s true everywhere: iOS development, Mac development, Windows development, web development, and most other industries in the world.

When you work for someone else, they’re taking the risk (or already have). You get paid regardless. (Well, most of the time.) The downsides are that your earnings are effectively capped and you have far less control over what you make.

This is a good balance in most cases, including development, because there isn’t enough demand for individual mainstream apps from every developer capable of writing them. In other words, just because you can write and sell your own app doesn’t mean that there will be a substantial market for it. Imagine if 1,336,300 people in the U.S. alone each designed a new kitchen utensil: a few thousand may be useful to a good number of people, but the rest probably won’t be different enough to be noteworthy, will solve problems that too few people have, or will simply suck.

Michael Jurewitz’ excellent Understanding App Store Pricing series inspired both aforementioned articles. In Part 4, he details why not every app can command a high price:

Above all, build software to meet a need and don’t become a commodity or enter a commodity space. Not all needs are equal. I need air way more than I need another drink cozy. Weather apps and Twitter apps are fun, beautiful, and engaging, but they are also very difficult to earn sustainable revenue.

He’s right. The issue with the iOS market is about more than price: it’s about demand.

I currently have 91 non-Apple apps on my iPhone, but I only use about six of them frequently. The rest are mostly utilities for specific, occasional needs, or games that I played for a few hours a long time ago and don’t have the heart to delete. Six is probably below the average for frequently used apps, but I bet this ratio isn’t too far off the mark.

My Big Six — Instapaper, Downcast, Reeder, Tweetbot, Instagram, and Dark Sky — solve big problems exceptionally well, and with the exception of Instagram, these are problems I’ve used apps to solve for almost the entire time I’ve owned iPhones.

I haven’t always used these particular apps to solve these problems, but it takes a lot to change my mind on one. If you make another RSS reader or Twitter client, there are certainly a lot of people who could use it, but you’ll need to compete with very mature, established apps. Competing in these categories isn’t about price: it’s about relevance and attention. If you can’t find enough customers here, it’s probably not because you’re charging $2.99 instead of $1.99 or $0 — it’s because your app isn’t convincing enough people that it’s worth using over the alternatives.

For these “Big Six” apps, price is almost irrelevant. If your app is useful enough for many of its customers to use it almost every day, they’ll pay a decent price for it. (Not all of them will — but you don’t need all of them.) The challenge is either making your app that much better than the alternatives, or finding new app roles that are that useful to a lot of people.

If you eschew common app categories and try to address a smaller niche to give your app a better chance of standing out, you run a different risk: your niche might be a lot smaller than you think. Usually, this happens:

  1. Paid app isn’t gaining traction.
  2. Developer lowers the price to boost purchases and climb the ranks.
  3. App doesn’t sell much better, and developer just makes less money.
  4. GOTO 2.

I’ve seen so many developers fall into this trap, even with good apps: an app can be good but not compelling enough to attract many customers. A game can be beautifully crafted but just not fun.

This isn’t a pricing problem.

Pricing does skew the market in other areas, and the App Store’s poor design exacerbates much of the dysfunction in its dominant top-list culture. And pricing can sometimes hinder an app’s chances of success by its nature: if your app has a substantial social component and it isn’t very useful without it, you need as many people as possible to start using it as quickly as possible, so social apps must almost always be free.

That’s not really a pricing problem, per se. It doesn’t matter what your price is — it only matters whether you charge at all, because that slows the rate of new users. This is complicated because you’re not giving people much value in the app itself: you’re relying on the customers to provide most of the app’s value to each other, and you probably need a lot of them to give substantial value to any of them. Social apps must therefore almost always seek indirect, deferred revenue because having as many users as possible is worth much more, long-term, than hindering growth with a paywall.

Since a few successful social products have been so big and high-profile in the last few years, many people mistakenly assume that the must-be-free rule is the new norm for all web and software markets, but that’s not the case. Even in social, it’s a massive gamble — since they rely so much on being extremely widespread to have much value, most social products don’t succeed. There’s not much of a “middle class” of social products. The big ones get bigger, and unsuccessful attempts become nearly worthless. Chris Adamson’s theory is actually correct in the social market, but these rules don’t apply to non-social categories.

In most categories, if you either solve a new problem that a lot of people have, or solve an old problem in a new and better way, you can sell a paid app today just as well as you could in 2008. In fact, the market is much bigger now. But, as with any maturing market, you’ll need to do more to get noticed since so many problems have already been solved so well.

The bar is higher, but the market is fine.

You don’t need every customer

Every well-read site gets comments. (For people like me who don’t let others publish comments directly on our articles, we still get plenty of commentary — just in other places such as email, Twitter, and Hacker News.)

Every app with a nontrivial number of downloads is likely to have comments, too, in the form of App Store reviews. This goes far beyond the app market these days, with stores like Amazon allowing anyone to review products and media, and sites such as Yelp that will publish anyone’s review of any restaurant, doctor, or church.

If you put yourself out there at all by offering a product or service, you’re going to get comments, usually anonymously and outside of your control, potentially inaccurate, malicious, or not credible, yet available for all future prospective customers to read.

Now, think of something you saw recently that had a lot of comments or reviews. They’re not all going to be positive. What could its creator have done to please all of the negative commenters?

Go ahead, this isn’t a trick question. You know the answer.


No matter what you make or how much you charge, some people will find things to complain about. If you drop your app’s price all the way down to free, people will still complain — just not about the price. They’ll move on to the features, the implementation, the design, the updates, the way you look, or what kind of dog you have. They’ll complain about every facet of your app, and then they’ll complain about unrelated topics just to pile on. They’ll say they use your app every day and love it, then give it a two-star rating until you add their pet feature. They’ll drop you from five stars to one star after an update that broke their edge case, then never come back to update that review after you fix it. They’ll complain that your productivity app isn’t a very fun game. They’ll scream at the world that your app is “useless” because they don’t like something about it. They’ll jailbreak and install a bunch of hacks that make your app crash, then leave you a one-star telling everyone that your app crashes constantly without mentioning their hacks.

You will never please everyone. You will never win that battle.

When evaluating complaints, we need to consider whether the complainer is credible, whether they have reasonable expectations, and whether a significant number of others have made similar complaints or are likely to have experienced similar problems. For many complaints, a reasonable outcome isn’t possible or pragmatic, and the best solution is to ignore them.

Developers are usually able to maintain a healthy balance of knowing which feature- or design-related complaints are worth paying attention to and which aren’t. So why is it that we lend so much credence to every person who complains that our $3 app is too expensive?

Someone saying they won’t buy at your price is just one data point. Each sale of your app is another data point. If you sell 100 copies of your app and get 3 comments on Twitter from people saying it’s too expensive and they won’t buy it, I’d say you’re doing great.

It’s impossible to get every customer. Fortunately, you don’t need every customer. If you sell a 99-cent app to just 1% of the people who bought new iOS devices in the 2012 holiday quarter alone, you’ll clear about $519,750. Not a bad quarter.

The most important input for your pricing is quite simple: are enough people buying it at its current price? If not, you might have a pricing problem, but not necessarily. If enough people are buying it, you face the interesting question: can you charge more?

The next generation of Instapaper

When I launched Instapaper in 2008, it was a very basic web app. It quickly expanded to define the pillars of the read-later market: a one-click “read later” bookmarklet, a web sync service, an adjustable text view optimized for reading, and an iPhone app with offline saving. I did almost everything myself, which worked well for the first few years, but for the past year, I’ve had a lot of trouble keeping up with it.

Instapaper is much bigger today than I could have predicted in 2008, and it has simply grown far beyond what one person can do. To really shine, it needs a full-time staff of at least a few people. But I wouldn’t be very good at hiring and leading a staff, and after more than five years, I’d like an opportunity to try other apps and creative projects. Instapaper needs a new home where it can be staffed and grown, but I didn’t want to give it to a big company that would probably just shut it down in six months.

A couple of months ago, at 1:30 AM, I suddenly realized who should take it over. I jumped out of bed, tiptoed downstairs (no parent wants to wake a sleeping baby), and sent an email. It didn’t take much convincing, because we both knew it was a great fit.

I’m happy to announce that I’ve sold a majority stake in Instapaper to Betaworks. We’ve structured the deal with Instapaper’s health and longevity as the top priority, with incentives to keep it going well into the future. I will continue advising the project indefinitely, while Betaworks will take over its operations, expand its staff, and develop it further.

I’ve known Betaworks for years, and I’ve spent a lot of lunches at their office. They have great engineering talent, great product direction, and plenty of experience running services at Instapaper’s scale. I wouldn’t put Instapaper in just anyone’s hands, and I know that they’ll do right by it.

With Betaworks’ drive and resources now behind it, I’m confident that Instapaper has a very bright future. I’m looking forward to seeing what they can do.

Wanting it more

John Siracusa’s excellent “The Lottery” summarizes most of my thoughts on the unexpectedly quick (and unexpectedly random) WWDC sellout.

What made WWDC so special to my friends and me in the past is that you could see the same core community there every year, because we were the ones who cared so much about getting tickets that no surprise or inconvenient timezone would stop us. The last few years, we’ve been on high alert for the entire month of April, and when tickets went on sale last year (and sold out in 45 minutes), most of us easily bought our tickets within the first five minutes. We were ready.

Every year, that community got larger and larger, but the conference’s size has been bounded by practicality and its venue. Apple has faced a significant problem growing the conference: every year since 2008, some people haven’t been able to get into WWDC who wanted to. And every year, that number has grown substantially.

Before, it was effectively merit-based: whoever cared the most (and had the money and ability) to get a ticket could get one. Now, no matter how much you care and no matter how early you get there, it’s a lottery.

Many people complained that Apple’s sudden availability in previous years was unfair, and they were right. Everyone didn’t have a fair chance at getting a ticket — only the people who devoted the most to getting one had a good chance of it. Most people who weren’t expecting tickets to go on sale soon, didn’t create or use alerting systems (or slept through them), or just needed time to get approval from their bosses were locked out last year.

This year, by giving everyone advance notice for the first time, Apple did fix that problem: it is more fair. A similar percentage as last year of interested developers got tickets (or didn’t).

But now, that core community that I’ve enjoyed for years is fragmented. Our elaborate hacks and dedication previously allowed almost all of us to get tickets, but now, we have the same success rate as everyone else: some got tickets, most didn’t. Apple eliminated our unfair advantage.

It’s hard for Apple to come up with a better solution if fairness is the goal (and it probably should be). This is the new normal.

I’m going to miss what we had. But like everything else in this business, it was temporary. That’s what makes it such an exciting business. WWDC will go on, but it’s going to be very different for my friends and me. Here’s hoping that the community finds creative ways to replace what will be lost. Fortunately, it usually does.

Replacing WWDC

Every year, Apple tries to address the excessive demand for WWDC in new ways.

They already make the WWDC videos available promptly after the conference to all registered developers — and every year, they come out faster. They already periodically send the small Developer Evangelism team around the world doing small “Tech Talks” (free, one-day mini-WWDCs, effectively), and they give attendance priority to people who haven’t attended WWDC.

It hasn’t helped.

Developers usually suggest expanding the conference or having more conferences throughout the year, but both of those have big problems. Jeff LaMarche explains why and proposes a sensible expansion idea, but I don’t think Apple would do it, and it would probably only increase the number of available tickets by two or three times at most — the additional scale may ruin the conference, and when you’re already selling out in less than a minute, it’s not going to make a huge difference to availability.

Daniel Jalkut came up with the creative proposal of Apple ending WWDC entirely, then addressing our demands by significantly expanding the online developer resources and documentation. This sounds plausible on paper, but would crush the spirit of our community. Apple should certainly expand the developer resources, but WWDC provides a lot that online resources can’t.

WWDC has an energy. It’s a huge rally to juice developers’ confidence and enthusiasm for the platform. Every year, I’ve been filled with an insatiable desire to just make something the whole time, and that energy gives me a boost for months afterward.

The reason we all want to go so badly is because it’s great.

When you go, you’ve allocated that week to learning this stuff. That’s your only job. You leave most of your workplace and family obligations behind for a week so you can spend all day in sessions, meeting great friends and colleagues in the industry, and immersing yourself in the technology, community, and culture.

Some of the academic and technical benefits can be had outside of that environment, but watching the videos alone at home doesn’t bring the spirit of actually being there. And since watching those videos at home is never going to be your all-day-every-day-for-a-week job, how likely are you to actually watch many of them?1

And while the usual community has been disrupted and we’re likely to see continued growth of the smaller, independent conferences, WWDC is still going to be the big one: the one that most of us try to attend every year, the one that matters most, the one with the best access to the most people (Apple or otherwise), and the one that Apple kicks off with an enthusiastic keynote that excites us with new OSes, new features, new APIs, and potential new markets for our apps.

No matter what Apple does to address the extreme demand for WWDC, that demand will always be there as long as so many people want to develop apps for Apple platforms, and no amount of videos or documentation can replace the real thing.

  1. Personally, I always miss a few sessions that I tell myself I’ll watch on video when they come out. I almost never have. The videos serve as a reference when I look something up, but it’s just never “the right time” for me to sit down and watch a session video just to learn about something cool that I don’t necessarily need right now.

    I’ve asked other developers, and this seems to be the case for most of them. ↩︎