So you want to build an App..
I’m contacted a few times a month by people who want to build (usually mobile) apps. Or more properly, want someone to build apps for them. While I don’t begrudge or criticize their hopes or goals, we need to look at things critically and honestly. Also, I’m tired of telling people the same thing over and over again.
Let’s start with some assumptions to calibrate who I think you are:
- First, you probably aren’t a developer. You might be a degreed/certified professional (actual engineer, doctor, lawyer, etc) with domain specific knowledge but you don’t cut code.
- Next, you probably aren’t well-connected or active in the tech community.
- Next, you aren’t a Kardashian. (More on that later.)
- Next, you’ve seen others “make millions” with their ideas and your idea is “way better” than theirs.
- Finally, your idea is so good that you don’t want to share it with others.
Now, before we start dissecting this, understand that this isn’t criticism of you, your idea, or anything similar, this is generic advice and thought that applies all over.
First, I think it’s awesome that you’re interested in technology. The problem is, I’m not sure you really are. After the Social Network showed how a bunch of hoodie-wearing bros made a pile of money overnight — not true, but it’s the common takeaway — people flocked to startups as the new gold rush. The same thing happened 1995–2000 before the crash. But I’ll give you the benefit of the doubt.
Next, very few people make significant money with apps. It’s not impossible to make money with apps, but the vast majority won’t. In fact, many people don’t even earn back the $100 annual fee to release apps in Apple store. If you don’t believe me, check out the Forbes article from May 2015 where a top 10 paid app maker earned $302 the day it peaked. Remember, that’s the peak! If you’re Kim Kardashian, you might make $200 million with your app, but that is an outlier among outliers.
Next, your idea probably isn’t that good. It’s not that all the good ideas are taken — though there are already probably a half dozen variations of your app — the problem is that you’re keeping your “great idea” to yourself. What you should be doing is telling everyone who could be your customer about your idea. Get feedback, listen to criticism and concerns, and refine and adjust your idea. Some feedback will be junk, but the useful parts will make your idea better. Also, skip talking to your BFFs. Instead, talk to people who should buy your app and learn from them.
Next, writing code is the easiest part. Before I lose my Developer Card, note that I said “easiest” not “easy” and this is in the realm of Tiger Woods making something look easy. When I wiggle my fingers on a keyboard to write code that works, there are years that went into knowing how to structure things, how they fit, what not to do, etc. But no matter how well I do my job, you still need to get out there and sell it. And once you sell it to a couple people, you need to sell it to more and more. Once again, that part is easy if you’re a Kardashian but you’re not so you’ll need a website, advertising, referral codes, etc.
Next, you need to maintain the app. Just like a car or a home, there is regular maintenance like software updates, security patches, new features, dozens of other things, and then re-testing all of it. Just because it is “done” for now, doesn’t mean it’s DONE. You need to budget for this. In fact, testing is so big and hard, there are companies like Testlio that focus entirely on that.
Next, this isn’t a passive income stream. Beyond the technical maintenance, there are customers involved and they have problems, need refunds, complain, and write reviews. You need someone to provide support and respond to issues. You need to budget for this.
Finally, there are lots of steps you can take before you hire a developer. You should take them. It will cost you less in discussion, debate, confusion, dead ends, and time. Here are six things I recommend that everyone with an idea should do:
- First, write a paragraph about what the app is. Until this is on a physical sheet of paper, it doesn’t count. Having it in your head is great, but that allows you to not think through implications, contradictions, etc. Putting it on paper exposes those things. And if you say “Facebook but for X” stop immediately. Facebook is the “Facebook for X.”
- Next, write a paragraph on what that app is not. The same applies as above but this also helps you draw some boundaries and inform your developer, team, etc what not to do.
- Next, do some serious research into your competitors. Don’t google it once and call it complete. Spend at least a few hours finding potential competitors and describe how you are different from each. Even better, find some competitors who have gone out of business and describe what you’re going to do differently.
- Next, use a tool like Balsamiq to sketch out your user flows. This means you draw the opening screen, show what the user does next, what that looks like, what they do next, etc. It doesn’t have to be beautiful and your final app probably won’t look like this, but you’ll be forced to think through implications, contradictions, etc.
- Next, start thinking about thinking about the bare minimum version that you can put in front of someone where they can still do something useful. This is called a Minimum Viable Product or MVP. It’s not the final system but enough to validate people will pay for what you’re building. For example, if you want to build a game with 50 levels, figure out if you can launch it with 5 and then do it. You can always release version 2.
- Finally — and throughout this entire process — start setting aside some money. Very few good developers will work for equity and they shouldn’t and even fewer will work to “build their portfolios” so don’t try that line. This amount will usually be five figures — not my area of expertise, so I can’t be more specific — but I’ve seen it go into six figures. Regardless, figuring out all the above will decrease this number a bit.
Isn’t this fun?
If you’ve made it this far, you should feel overwhelmed. What you probably thought was “a weekend project for a good developer” has suddenly turned into something much more than you’d considered. If you decide to bail at this stage, no harm, no foul. At this point, you’ve spent some time (probably hours) and a little bit of money (less than $50) but you haven’t broken the bank or wasted months of your life.
But if you decide to go forward, you will have a much clearer understanding of what to build, what not to build, which competitors to emulate, which to distinguish yourself from, and realistic expectations of what will happen. In fact, you should check out “Avoiding a Goat Rodeo” from my good friend Cal Evans. While it’s about website development specifically, many of the same points apply.
Keith Casey currently serves on the Platform Team at Okta working on Identity and Authentication APIs. Previously, he served as an early Developer Evangelist at Twilio and before that worked on the Ultimate Geek Question at the Library of Congress. His underlying goal is to get good technology into the hands of good people to do great things