Learn How To Build An App (Via Kevin Rose)
Hello dear,
Earlier this year, Kevin Rose announced he was working on a new meditation app.
Of course the meditator in me thought this was great news (and he was right, Kevin’s meditation app is the only one I use/ recommend nowadays).
Most importantly, the app builder in me was thrilled!
Why? Because Kevin documented the entire process on this Facebook group.
Finally, we got a chance to peek behind the curtain. Kevin shared everything including his research, wireframes, designs, how he picked a name, and even the costs!
I wish I had access to this years ago. It would have spared me many many headaches.
On the bright side, you get access to it all! I condensed everything into this letter.
Enjoy.
Sidenote: I’ll keep this iOS-centric, because Oak is an iOS app. If you’re building for Android, just find the Android equivalent of each service. Which platform should you build for? Whichever one your users use. If unsure, build for whatever platform you use. Either way, build a native app (it provides a better user experience, the most important thing is user experience).
Step 1: Research
Whatever idea you have, it is a good plan to go out there and play with your competition.
Find the best apps related to what you’re doing (e.g.: Kevin downloaded a bunch of meditation apps). Download them on your phone and use every single one.
This allows you to figure out two things:
- Is there an app that already does everything you’re looking for? If so, there’s no point in building another one.
- What features do you really like? Maybe you can duplicate some. Hardcore Silicon Valley fans are reminded of the mantra “good artists copy, great artists steal.”
Recommended — Spreadsheet
Don’t just use the apps and forget about them.
Track all the data using a spreadsheet. Narrow it down to four apps (either your favorite ones or the most popular ones).
This will give you an overview of the content they all share, their pricing strategies, their social features, etc…
Sidenote: This process takes a long time! It can take weeks depending on your app.
Here’s Kevin’s research. Below you’ll find a screenshot of it (just in case the link doesn’t work).
In this video, he guides you through it all.
Step 2: Wireframes
Did all your research? Fantastic.
Next up, turn your ideas into wireframes.
Use any app you want. But lately Sketch has been all the rage in the design world because of how simple/ clean it is.
I highly recommend you download Sketch and watch a couple of tutorials. It will be a great investment (even if you don’t build apps).
Now, lay out everything you wish to see in the app.
Keep in mind this isn’t the app you’ll initially build. The first version will be simpler (in order for your app to succeed, you need to do one thing better than anyone else, so don’t go crazy with tons of features).
What the wireframes do is give you direction (and allow you to gather feedback).
Below are Kevin’s wireframes. Notice how he shows the flow of information using red boxes and descriptions (don’t expect your team to just “get” your wireframes without any explanation).
Step 3: Mockups
Next up, we need to turn those wireframes into beautiful designs.
You’re a designer? First off, I envy you. Secondly, you can skip this part since you’ll naturally do everything I’m about to say.
Inspiration
You need to establish a visual tone for your app.
A Pinterest board will be super helpful. Pin designs that you like.
When thinking about your app, what words come to mind? (cute, friendly, serious, professional, relaxing, exciting, etc…)
Write them down. This will help you find the perfect look for your app.
Find A Designer
If you’re not a designer, I recommend you find one.
How? Use a service like Dribbble, Behance, or 99Designs.
Shameless plug: You can also email my friend, Alejandra. She doesn’t have a website (yet!!), but she’s an awesome designer.
You’ll probably spend HOURS looking at hundreds if not thousands of different designers until you find the perfect one.
Sidenote: Some people say design isn’t important despite Apple proving them wrong for the past 40 years (and counting). For those people, this Paul Graham essay will be helpful.
Make sure you get a standard contract for freelance work. Some websites (like 99Designs) handle this for you. But Kevin used a Silicon Valley law firm, Gunderson Dettmer.
Design The Mockups
You don’t just “hand the wireframes and get a design back.”
You’ll have a series of back and forth iterations with your designer.
To make this process easier, avoid what normally happens where people end up with thousands of files named file_1, file_2, file_3, file_1revisited, etc…
Use Abstract. It’s version control for designs (like Github with commits and all that stuff). Your designer will thank you.
Tap That App
After working with a designer, your ugly wireframes will turn into beautiful mockups.
Below you’ll see Kevin’s initial mockups (even though the final app looks different).
However even this isn’t final!
Seeing the design is one thing, making sure the app’s flow makes sense is another.
To get you closer to the real thing, use InVision.
This will allow you to see the designs on your phone and tap through them as if they were the real app. Trust me, it will feel very different from static designs.
Step 4: Build
Finally, you can start building!
If you can write code, you’re in great shape. You’ll build the first version yourself and hire people for select areas as you go.
What about the nontechnical people out there? Not to worry. Keep in mind Kevin is also “nontechnical” (along with others like Steve Jobs, Jeff Bezos, Elon Musk, Marc Benioff, Michael Dell, Brian Chesky, Ryan Hoover, etc…).
You simply need to find a technical person (but you still have to do most if not all of the 30 other things that aren’t software development).
Sidenote: If you want to work on software, I still believe you should learn how to code. At least the basics. I know many people will disagree with me here, but speaking the language and understanding what’s going on is super important. If you want to build iOS apps, you can start learning using Apple’s Swift Playgrounds iPad app.
Tools
Here are same tools to help you build the app.
- Backend: To keep your user’s data, use a service like Firebase (Google) or CloudKit (Apple).
- Analytics: It’s a mess. All services aren’t great in one way or another. For example, Facebook Analytics is great for audience metrics (gender and age breakdowns) but not so good for event metrics. It really depends on what you focus on for your app. So pick between Facebook Analytics, Google Analytics, or Mixpanel.
- Videos: If your app has videos, host them using JW Player.
- Beta Testing: Only version 1.0 of your app should make it onto the app store. Before that, do all the beta testing using TestFlight. You can invite up to 10,000 beta testers before putting your app out there.
- Project Management: If you’re working with a team, use Basecamp to make sure everyone is on the same page.
- Record: It’s nice to document the app building process (if you share online, this also helps you get beta testers like Kevin did). Record your screen and edit videos using Camtasia.
Extra
What about focus groups, or A/B Testing?
Forget all that.
Focus groups died in the 1980s, and you shouldn’t worry about A/B testing until you have several thousand users.
Make sure you build something people want (more on this in later letters). Let the app stand on its own.
Do people use it? Do people like it? Do people share it?
Once it’s growing week after week and month after month, you can start thinking about building community features (like refer a friend and whatnot).
Magic Number
If you really want something to focus on (once your product is working and people like it), try to find the magic number.
What do people have to do X amount of times before getting hooked on your app?
For example, Facebook figured out that if people added 7 friends in 10 days, they’d be hooked. Naturally, Facebook worked hard to make that happen for every user (and I’d say it worked pretty well).
Right now, Kevin is trying to figure out how many meditations it takes in X amount of days to hook a user (this is why apps like Headspace have a 10-day meditation tutorial).
Step 5: Name
Ahh, the naming process.
Entrepreneurs hate this. It can take forever (Stripe knows this well). And you also don’t want existing names or any registered trademarks.
Hence why naming your app should be the LAST thing you do.
What did Kevin do? Create another spreadsheet!
- The first column showed his current five favorite names.
- The second column showed names he liked, but passed on.
- The third column showed terms he thought about when thinking about the app (this helps think of more names).
- The fourth column showed names he could end the app with on the app store.
You can do the same before deciding on a name.
A tool that might help is the OneLook Reverse Dictionary (which I love).
Just remember the name has to pass the “bar test.” Imagine you’re in a noisy, crowded bar and you have to lean over to tell someone the name of your app without having to spell it or say it again. Will they get it?
Once you found the name, get that domain!
Congrats! You now know how to build an app :)
And that’s it for today!
Today, we learned:
- How to build an app!
- How to do research.
- How to build wireframes.
- How to create beautiful mockups.
- How to build a beta version.
- How to find the perfect name.
See you next week (follow the series here to be notified).
Be well.
R
P.S.: This letter wouldn’t have existed without Kevin documenting all the hard work he and his team did. Make sure you download Oak (frankly the best meditation app I’ve used). Thanks Kevin!
Thanks for reading! 😊If you enjoyed it, test how many times can you hit 👏 in 5 seconds. It’s great cardio for your fingers AND will help other people see the story.You can follow me on Twitter at @richardreeze to find out whenever others just like it come out.📚 Do you like books? If so you might enjoy my latest obsession:
Most Recommended Books.📚
Since I write about finance, legal jargon is obligatory (because the guys in suits made me). Before following any of my advice, read this disclaimer.
