A Developer’s Guide To The Wild West Of App Discovery

Editor’s note: Raphael Ouzan is the founder CTO and head of product at BillGuard.

It’s hard to launch a consumer mobile app these days. Manage to build a stellar product that answers a true need? With more than 80 percent of the 1.4 million App Store listings qualifying as “zombies” – not visible on any of Apple’s category lists – it’s really not so surprising that most iPhone owners don’t download even one new app a month.

So if you’re a consumer app company that’s staked its future on user growth, you have to find a way to address this challenge head on. When we were just beginning to research mobile, I turned to my friend Ouriel Ohayon for advice and will never forget his response: “Oh man, mobile discovery is the Wild, Wild West.” Ouriel was of course right, but like the American frontier in days of old, it’s not that no rules exist, but rather that those rules can be extremely hard to ascertain when you first trot into Dodge City.


As a sort of communal payback for Ouriel’s help, here’s our developer’s guide to the Wild West of app discovery.

Lean Development — Even on iOS

Once you’ve decided to start on iOS or Android, there are two important decisions you have to make ahead of launch: how to structure your builds and how to coordinate your launch.

BillGuard began as a web app; we started coding our first mobile app in early 2013, which was late in the game. At that point it was clear that iOS was the place to begin for the demographic we wanted to reach.

As our early iPhone app development progressed, we realized we were in a bind. Apple’s app-submission process makes it hard to develop in a quick, iterative, responsive way, listening closely to early users and continually applying fixes and improvements. That’s the lean development framework that most software teams like ours prefer to work in today. TestFlight wasn’t much help: only a limited number of testers make it through the complex setup.

So we decided to roll our own version of lean dev for iOS — a cowboy cigarette.


We formed a Facebook-based beta group for power users and quietly released to them no fewer than 11 versions of our app before our public launch day. The feedback from this beta group proved invaluable toward a successful launch. 

To ensure we’d receive fresh opinions uncolored by our web app experience, we also bought some carefully targeted Facebook app install ads to draw new users and to begin to understand what marketing messaging worked well.

For example, in the ad creative, we floated a few different design alternatives to gain a signal on what drew consumers. That turned out to be very helpful in determining certain design elements like our app dashboard. 

It took about four months for our app’s quality to rise enough for a real launch. At that point, we pulled the app from the App Store so we could make a splash on our public launch.

Cowboy Tip #1: Stick to your developer’s guns – don’t let the structure of the app store determine your software release cycle.

Press. Harder.

We then turned to our press contacts and offered them a sneak preview of the app, which we had to engineer. We left our App Store status in ‘Pending Developer Release’ and slipped journalists a promo code supplied by Apple. The writers fortunately loved the app.

On launch day, we went live with a TV appearance, received a bunch of other great press that we had embargoed, and even received a featured slot from Apple.

Cowboy Tip 2: Take PR seriously. And remember – the App Store refreshes on Thursdays. Time your launch accordingly.

To Port or Rebuild?

Before we reached out to Google regarding our app, we began designing and coding it. Many developers structure their second platform app according to the same exact UI and design principles of their original app – porting it over – but we chose not to do that. We didn’t think the consistency of user experience on the two platforms really mattered. So we designed BillGuard for Android with a couple large UI changes from our iPhone app.

The downside of this approach is that when you learn something about user behavior on your new app, you don’t know whether it’s due to the platform switch or due to that particular feature. That’s a huge disadvantage — enough to make it the wrong decision for most apps — but in our particular case I don’t regret it. 

Cowboy Tip 3: Understand the advantages of each mobile platform and how you can improve your app on one platform based on the experience on the other.

Hit over the Head with a Tablet 

We developed a strong contact at Google who helped us through the Android launch process – a biz dev head in New York and his Google Play team, whom we met at SXSW.

We met personally with our New York contact every month, and as our app progressed the Google Play editorial team gave us a ton of detailed feedback, most of which we implemented.

Some of the feedback, however, seemed just wrong to us, and we pushed back. Google’s team actually accepted our position in some cases, which demonstrated that this was a real peer-like relationship – far from our Apple experience. Later, the Google editorial team even advised us on when and how to launch.

This was like telling a new sports car maker immediately before it goes to market that it can only open a showroom if it simultaneously releases a pickup truck.

Everything seemed to be going well until one day, late in our development process, our Google contact informed us that if we wanted to be considered for a Play Store featured slot we had to release not only a phone app but also a tablet app. Google wanted to bolster its overall tablet app quality, so it was only featuring new apps that launched on both phone and tablet screen sizes.

Our entire product development had focused on phone screens, and now if we wanted to be featured and avoid Android obscurity, we had to also build for a very different user experience for tablets. This was like telling a new sports car maker immediately before it goes to market that it can only open a showroom if it simultaneously releases a pickup truck. It felt absurd, out of character from the Google dev relations we had come to appreciate. But it showed how business considerations can force the hand of even the most dev-friendly Googlers.

We decided to comply, despite the additional time it demanded. And in the end, following some extraordinary help from our contact, Google did feature our app on launch day. As with Apple, setting up press coverage ahead of time — and letting Google know about it — certainly helped to get featured on the Play Store. 

We’ve found that attending Google I/O has been important to expanding our relationship with Google. While there, we’ve participated in a few, refreshing ‘reverse panels’ where Google folks ask us about the experience of building for Android. 

Cowboy Tip 4: Understand and align yourself with the strategic goals of Google and Apple – even if you don’t share them.

The House Rules

Our apps are now well-established on both the App Store and Play Store, and our launches were key to that. But in retrospect, we feel that the success of our launches had way too much to do with identifying and negotiating technical hurdles: Apple’s and Google’s frameworks, guidelines and secondary business interests.

Hopefully the day will soon dawn when app discovery improves such that the mere quality of a service determines visibility. Maybe Product Hunt will cross the chasm and become such a tool, or maybe Apple’s new App Analytics signals a commitment from Apple to enhance transparency for both developers and users.