How to Build a Killer Mobile App: 10 Tips

Imagine you’re a physician who also started two successful companies, one later acquired by WebMD and the other by Microsoft. And imagine you also ran Microsoft’s Healthcare Innovation Lab for five years.

So what do you do next? Build an app that turns mobile devices into speed radar guns for sports, of course.

Countless numbers of people dream of developing software products. And why not? Apps are infinitely easier to distribute than hardware and adoption can take place almost overnight–and so can the growth of a company.

But what if you’ve never developed an app?

That’s the challenge many aspiring software entrepreneurs face. So I asked Mike Gillam, the founder of Athla and creator of Velocity–a hands-free speed radar app for a variety of sports that works on iOS devices–to give me an insider’s look at the process from idea to initial development to refinement and even pricing.

(Quick note: I was drawn to Mike’s story because I would have loved Velocity when I was a kid. My friends and I would have obsessed over how hard we could throw. Hardcore Call of Duty addicts would have had nothing on us.)

Here’s how Mike did it. Read, learn, and then go build your own killer app.

Step 1: Don’t Design for Today

Two billion people worldwide never see a doctor, yet a billion of those people have cell phones–and that number will only increase. So I decided it was time to move from working with PCs to working in mobile. To do that, though, I needed to know how to program mobile devices, so I looked for a project in that space.

I also focused on creating something that was impossible at the time–trusting the hardware would catch up.

That’s a safe bet. Software always forces hardware to catch up. If you design for what is possible today, by the time you come to market, hardware advances will mean your app is already behind.

When I decided to put speed radar on a mobile device, the capability really wasn’t there, but I knew it would be.

Step 2: Winklevoss or Zuckerberg?

At that point, I faced a choice: Should I just hire someone to develop my idea? I already knew how to architect, lay out scopes, and guide developers. Or should I learn how to do the core coding myself?

I realized Zuckerberg was crucial to coding the early versions of Facebok. Bill Gates wrote core components for Microsoft’s early software. In health care, Judy Faulkner, the CEO of Epic Systems, wrote core code. Many successful CEOs were core to building key pieces of their company’s technology; maybe that’s a key factor in their success.

So I decided to build the prototype myself. That meant I had to learn GPU and iOS programming as well as OpenGL. (I had programmed in lots of different languages, but not those.)

I was told learning OpenGL was like stepping into a large, cold, deep lake; it felt like what I was trying to learn was at the bottom of that lake. So I needed some help, yet I also wanted to keep my idea under wraps. To stay in stealth mode while also leveraging the skill of consultants, I hired experts to build sample code for discrete portions of the prototype. Then I could learn from their code and rewrite the final code myself.

And that’s how I learned some pretty arcane and complex coding skills.

What someone could do in a day or two would then take me a week to figure out…but eventually I essentially learned to build the software from beginning to end. The process took time but turned out to make a huge difference.

Step 3: Go From Prototype to Product

Once I had a prototype, I got a ball machine, placed my iPad on the side of the court, and bought a $3,000 radar gun to validate my results. I soon realized the app worked better than I could have imagined. (Partly because the hardware had started to catch up with my idea.)

It was a hugely rewarding moment, one that opened up a ton of possibilities. But first I needed to turn my prototype into an actual product with an interface, graphics, etc.

That’s when I decided it made sense to bring in experts. I started with one team and realized it wasn’t a great fit. So I switched to Big Nerd Ranch and it was fantastic. (Big Nerd Ranch is so good that its people train Apple and Facebook employees.)

Still, as so with prototyping, I only had them do as much as I could learn from. They did the first two sports; from there I was able to do the next sports myself.

Step 4: And Make Sure It Works

What we’ve created is software that turns an iPhone or iPad into the equivalent of a $1,200 speed radar gun, one that is accurate within /- .7 mph. And it’s out of the line of play–you can set it up yourself, so you can practice and get immediate feedback all on your own.

But if it wasn’t extremely accurate, no number of features or graphics or slick interfaces would matter.

Step 5: Determine Pricing

I took a couple of different approaches to determining the price. First I did market surveys using Google Survey, which allows you to send out surveys for very low cost. I sent out 500 different surveys. One said, “We created the equivalent of a $1,200 speed radar gun. Would you pay $3.99?” Another said, “Would you pay 4.99?” And so on.

Unfortunately, the answer was “Yes” for every single category; the drop-off between higher price levels was very small. There was no classic price curve moment. So surveys didn’t really work.

Then I looked at Sensor Tower and evaluated the price points in related categories like sports and fitness and productivity. The No. 1 price point was $6.99, No. 2 was free with an in-app purchase, and No. 3 was $9.99.

So I decided to go with those numbers: $6.99 for one app, $9.99 for all four.

The goal was to set a price that allows us to create a business that will enable us to add more features. Our goal is to eventually make the basic app free so every kid can have it, which means we need to develop other ways to generate revenue to build a sustainable business. That’s the ultimate goal.

Lessons Learned

Here are a few things Mike learned along the way:

Insist on developer transparency. If you hire developers, insist on seeing the code and seeing it every step of the way. Your developers should be able to provide that to you.

Many won’t do code dumps, claiming all sorts of reasons they can’t. While their excuses might sound legitimate, too many excuses is a huge red flag.

Pull the developer plug quickly. It the relationship or service doesn’t feel right early on, it never will. Switch early.

Learn the core of your technology. Before I started, I thought I had a sense of what was necessary to build our apps. Turns out I didn’t. So I’m very glad I took the Zuckerberg route, not the Winklevoss one. The list of changes and alterations was huge.

Had I not known the code inside and out, the development cycles would have been endless. You don’t have to know everything, but knowing a lot will make a huge difference.

Embrace Moore’s Law. The iPhone 4 couldn’t run Velocity. Now the hardware can handle it. I took a shot that the hardware would catch up and, with the iPhone 5, it did.

Now the iPhone 6 may be able to process a 120 frame/second camera, which would allow Velocity to measure objects traveling up to 600 mph. The applications for our product will grow along with the power of the hardware, so we’re already designing for what should come next.

Don’t forget to build for a community. Part of the fun of performance apps is the ability to share, so we created GameLink to mirror speeds on up to seven different devices; that way, parents or friends can see what you’re doing. We also created FriendLink so people can use the Internet to share their results with coaches and friends.

People love to be a part of something bigger than themselves. No matter how technical your product, never forget that.

Like this post? Check out Tyson Cole on How to Start a Killer Restaurant.