How to Ensure Your App will be a Huge Failure

Analysis

After six years of building apps, I’ve come to see a number of common problems that can lead to an app’s failure. While it’s challenging to more precisely distill all the components that go into ensuring an app’s success—I needed a whole book to do that—lessons learned are often more concise and digestible. Here’s a a collection of some of the more typical issues that either lead to an app’s demise or reduce its ability to succeed.

TL;DR

  • It's a business, not an app. Prepare to deal with issues beyond just development.
  • Keep to your timeline. Don't fall to the allure of “more is better.”
  • Collect feedback and create a roadmap to avoid losing touch with users.
  • Dedicate 20% of your timeline to beta your app.
  • Plan for a long enough runway to prove out your idea.

It's a Business, Not an App

In my 2014 talk at Renaissance.io, I challenged attendees to stop looking at themselves simply as developers. Developers typically do not think about marketing, financials, legal issues, customer support, and other similar elements required to run a business.

The point is that even a solid app can fail in app stores without these other critical components. For example, I've regularly honed in on marketing in particular in the past —about 40% of App Savvy is dedicated to marketing—and we've written about it here as well. When we work with customers, we do much more than just design and develop their app. From day one we're thinking about positioning, assisting them with raising venture capital (when applicable), creating app-focused websites, and even populating customer support knowledge bases. There are very few apps that will go on to be successful without a more holistic business approach.

A responsive app-focused website we created for FamilySignal, arriving shortly on the App Store.

App Scope Creep

The best way to never give yourself the chance to be successful is to not ship your app. This happens more than most people know—it's not a problem specific to apps—and a primary culprit is typically scope creep. Scope creep can include allowing one feature to become bigger than it should be, adding more features to a release than it should have, or some combination of the two.

Why scope creep happens is partially wrapped up in the human psyche that "more" is better. More features means more downloads and more success. As I've detailed in the past though, such a philosophy is especially not true in today's app stores. Look to do one thing really well. When you've done that...ship it

Founder Blindness

App scope creep is one symptom of founder blindness. Founders can become obsessive about a particular feature, get distracted by new ideas, or lose touch with what's important to normal users. Essentially, because of how close they are to their idea, they have a propensity to get off course.

There's a few ways to combat founder blindness. The first is to ensure that there's a roadmap for your app. A roadmap outlines upcoming features to focus on, bugs to fix, and the like. For each app we're working on, we have a shared Trello board with our customer with at least the next 2-3 releases planned out. That's separate from our much more detailed development tracking tool. In the roadmap, there's also a staging area for potential features.

Leading up to the v1.0 launch, we had a series of internal releases to a beta group of nearly 500 testers.

Another great way to address founder blindness is what Steve Blank describes as "getting out of the building"...interact with those using your app. Founders should read app store reviews, be active in their support inboxes, and otherwise try to talk with their users. Check the Basecamp blog for a recent post about how they take off the developer goggles.

A corollary to this point is to regularly look at hard data. Founders can quickly overcome an absolutist position by relying on analytics from the front or backend. Data can help founders understand how a bug they're experiencing is limited to extreme power users like themselves or provide better context that all the extra effort put into a screen that no one is using is obviously not a good use of time. We're big fans of Google Analytics and Mixpanel for client-side reporting (i.e., from the app) or what comes out of the box with back-end platforms like Parse.

Little to No Beta Testing

Before it was unveiled publicly, Gmail existed for years as an internal project used by employees at Google. It then moved into a public but invite-only phase until anyone could sign up for it.

Google can be thanked for championing the concept of beta—and especially public beta—testing. What many people fail to recall is that they kept Gmail in beta for about five years. That sort of timeline is almost assuredly not possible—or recommended—for most developers. It's useful though because if there was one side to err on, it would be a longer beta testing period, not a shorter one.

A common mistake I see is that many app entrepreneurs do not account for any beta period at all. Schedules are often aggressive with launch dates coinciding almost immediately with feature completion. This leaves no time for refining experiences based on feedback, tweaks and polishes, or additional bug fixing. Ultimately, this leads to the launch of a lower quality app.

The right length of a beta period is a whole separate topic. As a general starting point, we suggest at least 20% of your entire development timeline should be dedicated to beta testing a near production-version of your app. This means if your timeline consisted of five months to ship an app, at least one of those months would be dedicated entirely to beta testing. During that time no new features would be in progress...at all. While not possible for everyone, if you can afford to, stay in beta or in a limited rollout as long as possible.

No Vision Past v1.0

Many app store entrepreneurs have a "submit and prosper" mentality. That is, get an app submitted to an app store, then start collecting checks.

There aren't many Angry Birds, Instagrams, or Ubers out there though. In fact the developers behind these apps in large part struggled to find their own way. Rovio took about six years to create Angry Birds. Instagram started as a different app altogether. Uber had a slow, staged rollout because of the infrastructure required, along with needing to prove out their model.

The ideal length of beta testing and the necessity of an app roadmap are both indicators that you need a vision for your app beyond launch. If your runway—the length of time before you run out of money—only takes you up to getting into an app store, you're in trouble. A good rule of thumb in today's market is that you need at least a year to prove out your idea. That may seem like a long time and that's why depending on the scope of the idea, many app entrepreneurs decide to raise money

Concluding Note

Although not exhaustive, this post should be instructive to anyone looking to get started on the app stores. Thankfully there's a great community of developers who regularly share their own experiences on Twitter, Medium, podcasts, and many other places. Again, none of those particular anecdotes will necessarily guarantee you'll succeed. Anything and everything though that you can avoid or be aware of will put you that much closer to seeing your app—your dream—be a sustainable reality.

Ken Yarmosh is the Founder & CEO of Savvy Apps. He's the creator of more than 20 featured apps, including an Editor's Choice selection and Starbucks Pick of the Week. An O'Reilly author, Ken regularly speaks about application design & development, as well as the future of technology at outlets ranging from Bloomberg TV to Google.

You made it this far so...