Developer’s Guide to Choosing an App Idea (Part 1)

Most of us developers are starting to wake up to the fact of how crucial our skill set is to the modern world of business. If a person with a non-technical background has a fantastic idea for an app (we’ll talk more about what this even means later), they can’t just go home after work, turn on their computer and start banging out code. They need to invest some amount of capital into getting their idea built for them. However, developers have the distinct advantage of owning the means of production in today’s digital marketplace. So how come all developers aren’t driving around Ferrari’s and shopping for yachts?

Many developers I know are smart, capable, and industrious, but don’t quite have a direction when it comes to building a business out of a side project. My goal is to provide some concrete guidelines around this nebulous subject, and hopefully help a few developers reach their goal of shipping a product and owning a business.

Picking an “app idea” is a strange and complicated subject. Many people reading this have probably been subjected to some friend or family member approaching you with a “ground-breaking” app idea that would rake in billions if only they could get a developer to translate their amazing idea into code. We, as developers, collectively roll our eyes when we hear these ideas (“It’s like Uber but for sea urchins!”) and move on with our lives. However, when we get put into the hot seat of choosing a product to create, how do we choose the way forward?

Turns out sea urchins are actually pretty cool. Photo by NOAA on Unsplash.

Paralysis By Analysis

The way that I first approached this problem was what I now think of as a bottom-up approach. I would agonize for months about what tech stack to choose for this imaginary business that I wanted to create. Despite not having a clue what sort of product I was going to create, I would internally debate on whether or not to learn Swift to build my imaginary app. I think for most of us, this is a pretty common trap to fall into. We love technology and we want to be spending our time working on technology problems. We’re also trained to think this way as line-level developers at larger companies (more on this later). This method usually results in indecision, losing interest, and then giving up on the project altogether. The reason this happens is because we’re putting the cart before the horse. If our goal is to eventually have this app earn us extra income, wouldn’t it be helpful to see some evidence of that before we invest time into learning a new language or technology?

Choosing a tech stack is always a blast when starting a new project. But is it the priority? Source

The core issue here is that even if you do make it through the pit of indecision, you now have a very high probability of building something that no-one wants or is willing to pay for. I can say from experience that it is not fun to spend a year working 60+ hour weeks (40-50 hours at your regular job, 10-30 hours on your side business) only to have a nice shiny new app that no-one actually wants. Our focus going forward will be how to help you avoid that situation entirely.

In the next installment, I’m going to talk about a much better approach to choosing an app idea (hint: start with the customer!). In the meantime, I’d highly recommend checking out the book Developer Hegemony by Erik Dietrich and his corresponding blog at I found this book extremely empowering as a developer and it helped me form many of the ideas I’ll be discussing in this series.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: