Mobile app startups are failing like it’s 1999

Stop the madness
The long cycle times for developing mobile apps have led to startup failures that look more like 1999 – it’s like we’ve forgotten all the agile and rapid iteration stuff that we learned over the last 10 years. Stop the madness!

Today, seed stage startups can now get funded, release 1 or 2 versions of their app spread over 9 months, and then fail without making a peep. We learned the benefits of how to iterate fast on the web, and we can do better on mobile too.

How things worked in 1999
How’d we get here? Back in 1999, we did a similar thing:

Raise millions in funding with an idea and impressive founders
Spend 9 months building up a product
Launch with much PR fanfare
Fail to hit product/market fit
Relaunch with version 2.0, 6 months later
Repeat until you run out of money

This was Pets.com, Kozmo, and so on. Maybe you’d fire your VP Marketing in the process too, out of frustration.

Between 2002-2009, we learned a lot of great ways to work quickly, deploy code a few times a week, and get very iterative about proving out your product.

How things work today
Then, with the arrival of the big smartphone platforms, we’ve reverted. It looks like 1999 but instead of launching, we submit into the iOS App Store.

It looks like this instead:

Raise funding with an idea and impressive founders
Spend 6 months building up a product
Submit to the app store and launch with much PR fanfare
Fail to hit product/market fit
Relaunch with version 2.0, 6 months later
Add Facebook Open Graph
Try buying installs with Tapjoy, FreeAppADay, etc.
Repeat until you run out of money

Not much different, unfortunately.

The platform reflects its master
We’ve gotten here because the App Store reflects Apple’s DNA of great products plus big launches. They are a 1980s hardware company that’s mastered that strategy, and when developers build on their platform, they have no choice but to emulate the approach as well.

Worse yet, it lets people indulge in a little fantasy that they too are Steve Jobs, and once they launch a polished product after months of work, they’ll be a huge success too. The emphasis on highly polished design for mobile products reverts us back to a waterfall development mentality.

Don’t burn 1/2 of your funding to get to a v1
Startups today have a super high bar for initial quality in their version 1. They also want to make a big press release about it, to drive traffic, since there’s really no other approach to succeed in mobile. And so we see startups burn 1/3 to 1/2 of their seed round before they release anything, it becomes really dangerous when the initial launch inevitably fails to catch fire. Then the rest of the funding isn’t enough to do a substantive update.

What can we do?
How can we stop the madness? What can do we do to combine the agility we learned in the past decade with the requirements of the App Store?

If we can answer this question, we’ll be much better off as an industry.

Like this post?
Get new updates via newsletter..

http://profiles.google.com/jeffpk Jeffrey Kesselman

As someone who has spent most of 25 years of engineering in startups, I actually I 100% disagree with you. The problem is not long development cycles. The problem is the expectation of short development cycles and fast returns.

Amazon, Google even Facebook all took many years between their commencement and any indication that they might be financially successful. Any new platform has a brief period at the beginning where you can ship any slapped together crap and probably make some money. That time is ending for mobile.

What we need is a return to what the early VC’s knew– that real companies with lasting value aren’t built in 9 to 12 months. That a proper run way for a new concern is 3 to 5 years of hard effort.
http://twitter.com/jacobespa Jacob Esparza

Thanks for the post Andrew! You summed up the story of the last startup I was a part of…

* the friction of TestFlight made it difficult to gain an adequate number of beta testers (I’m not blaming TF here, we could have done more in-person user testing)* fears of having our idea stollen, which created behaviors of not showing the app to anyone connected in the tech community or allowing them into our beta* fear you only get one shot a Launching in the App Store, which created the dependency for sellar design, more features than we had engineering bandwidth and a rigid PR roadmap
This created a situation of having a beautiful and completely untested product, with little room for error.
IMO – for mobile apps: it’s the community that wins, not the product. And as a startup community we’ve been optimizing for the product.
http://www.facebook.com/andrewhchen Andrew Chen

I think my point may not have gotten across- there’s two different topics we’re talking about:
1) How long does it take to build a company?

2) How long does it take to iterate, get feedback from the market, and update your release?
As you point out, building a company is hard and we should all expect it to be years, if not decades. I’m in violent agreement with you on that.

The point of my blog post is just to address the issues around the mobile iteration cycle. I think that can be improved.

As an example of how one doesn’t mutually exclude the other, Facebook deploys code twice a day to their web servers but that’s a company that will take decades to build up. YouTube (at least early on) had a weekly deployment cycle, and some of the best web companies have short iteration cycles as well.
http://www.facebook.com/andrewhchen Andrew Chen

I don’t think that’s quite it. I actually think a long-planned out business plan tends to inhibit iteration, since you aim into the future rather than focusing on shipping something this week. Mainly my post is about how might we, as an industry, increase the speed at which we iterate on mobile to days or 1 week timeframes, rather than months.
http://www.facebook.com/gordon.mcdougall.5 Gordon McDougall

Andrew you should consider interviewing the CEO at a company called Bitzio (www.bitzio.com) as they have a business model that addresses that by having an audience (huge fan bases) that want information on their team or player or celebrity. This is so much more effective.
http://twitter.com/JD_Hashomer Jake Diner

Nice writeup Andrew! I’d broaden your argument to the entire startup universe in general, regardless whereas it is based on a mobile or web platform. The reason they fail because they are solving problems large markets doesn’t care.

You are correct that shorter development cycles will flash out this issue earlier. What the company will do after that? Depends if the founders are really determined to match broccoli lovers within 5 miles radius based on their Facebook preferences via video chat or just decide to find another issue to tackle.
http://www.gordonbowman.com/ Gordon Bowman

“re-embrace the MVP”

Well said. I like that.
http://www.gordonbowman.com/ Gordon Bowman

That’s a great strategy @facebook-5723398:disqus

Another one of the strategies I’ve seen is to launch your v.1 in a small market like New Zealand first. New Zealand is a good market because the smartphone penetration is high, broadband is good, population is english speaking, and they have similar app behaviors as the U.S.
http://www.gordonbowman.com/ Gordon Bowman

Great post. +1 on not burning half your funding to get a v1

That’s why I’m excited by startups like Parse (@parseit). They are lowering the barriers to entry with things like mobile backend, social logins, and push. So app developers can focus on what matters (the frontend UX) and get out their v1 much faster.
http://twitter.com/scottvelicer Scott Velicer

very lean!
http://www.startupeconomy.com startupeconomy

I can’t stop laughing looking at the steps you laid out. So true. The App Store model is still evolving, and this definitely is the greatest process in the world.

One delusion that many startups (at least from where I sit) have is the whole let’s-get-featured-and-we’ll-grow-like-rocket-ship mentality. The editorial piece in the App Store is really nice, and consumers *may* get to see the high quality apps that they wouldn’t otherwise get to see. When apps get featured, *magic* happens. You see tens/hundreds of thousands of downloads (if not millions) in a very short period of time, and you look at that from the old point of view and believe that you find a product/market fit because you hit 6-7 digit user base. The reality is, it’s all gone when you’re not the new and shiny thing. You just can’t tell if there’s a product/market fit purely based on acquisition metrics.

One things to keep close eyes on is whether users really do stick around. Is the app a core utility in users’ life? It doesn’t necessarily mean that the app needs to be used on daily basis, as long as they come back at an expected frequency. Or, are people willing to pay for the product? These are better indicators for product/market fit.

I agree that you can’t burn 1/2 your funding for v1, because you can’t measure the true product/market fit purely based on user acquisitions like we used to do back in the web days.
http://www.facebook.com/daniel.grippi Daniel Grippi

with things like testflight (https://testflightapp.com/), you actually can be agile when it comes to app development. you don’t really need thousands of people using your app to validate your product; only a sub-sample is required to see if you’ve hit MVP status (which can be further validated by landing pages with pre-signup lists / see: the lean movement).

with something like testflight, you can do hot deploys to a control group and validate quite quickly. i’ve known a bunch of iOS devs that have done this with really successful results. fact is: you don’t need to be in the app store to validate or find obscure bugs.

so yeah, there are gatekeepers (apple / google / microsoft), which is a bummer, but not all hope is lost.

be nimble with mobile development! it’s possible!

(disclaimer: i don’t work for testflight)
http://profiles.google.com/nick.bauman Nick Bauman

Just curious: when was the last time you got an app through iOS app store approval? iOS apps are really expensive, both in time and in opportunity because you can’t iterate slowly, Apple won’t let you.
http://christianbusch.blogspot.com christianbusch

Great post, Andrew. I was talking to @aweinreich about this yesterday, as you’ll most likely fail on the first iteration, you have to be super-agile and humble in getting to v2,v3 quickly and cost effectively. And maybe one day apple will allow you to actually do testing on the platform!
http://www.facebook.com/people/Francesco-Ferrazzino/100001467532833 Francesco Ferrazzino

true story.
http://twitter.com/Tdoza33 Tyler mendoza

Fantastic article, as a founder of a mobile based company i have also seen several others fall into this same cycle. i would point out that as @nickbauman mentioned below it is tricky becuase of the gate keeper that is apple and google play, and finding the balance between quick iterations cash spend is hard to find.
http://profiles.google.com/jeffpk Jeffrey Kesselman

Well, if you are specifically referring to the MVP then I agree to some extent. I think you need to be careful however because to minimal an MVP and you can create a negative consumer reaction that can be hard to overcome.

The biggest problem I’ve seen though with the MVP oriented culture is that it can lead to flailing around. If you are committed to some core goals and what you are doing is adjusting the details to tune it, thats one thing and can be good. Theres a great opportunity in these new constantly connected platforms to really analyze and respond to consumer response.

OTOH if you want to pivot to something totally new every Tuesday because what you did last Tuesday didn’t get a great response, then you have a real problem in management. And Ive seen that problem more and more as of late.

I also think your Facebook example actually illustrates another trap you can fall into. Facebook hurt their developers and frustrated thier audience pretty badly when they were changing the functioning of their APi and their terms of usage every week. One of the most important positive developments in the Facebook world was when they committed to the GraphAPI and stopped the weekly breakage of apps.
http://twitter.com/jwilsjustin Justin Wilson

Mikael, what was your strategy when you reached the “get feedback” part? Who gave you feedback?
http://www.facebook.com/david.dupont.144734 David DuPont

Reading this makes me feel very good about TeamSnap’s lean approach. We spent less than 1% of our seed money getting an initial iPhone app out there and it accounts today for almost half our traffic.
Mike Newell

Your articles sounds really good in theory…

I build alot of prototypes using a combination of web technologies and ios devices…

ios is a hard platform to develop quickly on if you’re looking to do something more than using the camera or microphone.

Unfortunately, it’s hard to get to good beta without “really” building it. The web has flash, we don’t really have anything like that for ios.
http://twitter.com/bwhalley Brian Whalley

Andrew – I replied to your post and about how Backend as a Service is changing the game for this: “Saving Mobile App Startups” http://www.kinvey.com/blog/item/207-saving-mobile-app-startups
http://www.facebook.com/esbovee Erik Sebastian Bovee

Composing letters of apology to my old marketing VPs…
http://twitter.com/Gaute_Solaas Gaute Solaas

This is a great string and a timely discussion. Great observations all around. Good initiative Andrew!

We (IQumulus) feel strongly that much can be done by proper automation of application development and iteration going forward. With proper automation more than 90% of development and iteration can be automated completely, allowing developers to focus on the 10% that matter.
This will allow faster cycle times, near zero errors and a greater focus on business viability and outcomes. Check out our new demo video of the IQumulus Mikla, a visual mobile app assembler producing iOS/Android apps on-the-fly:
ylechelle

Yes, there is much to learn from the past. The gold mine rush is over. The app marketplace is now ultra competitive, ultra saturated and the bar is really really high.

That being said, building a great app is easier than ever with the great iOS 6 APIs, as Andrew says, a few months to get to v1.0. What’s more difficult now is trying to be novel or finding the right idea, especially when 650,000 instances are already filling most niches…

So first things first: build a compelling POC, solve a problem or innovate or provide high entertainment value, all without raising money (bootstrapping/love money only), make sure your App Score (http://blog.appsfire.com/introducing-the-appsfire-app-score-the-ultimate-quality-score-for-mobile-apps/) is up in the upper 80s (by then, you probably have already hit the gold mine or have iterated to version 2 or 3), and then, only then raise money…

@andrewchen