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 https://daedtech.com/. 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.

Should You Use Xamarin.Forms?

Based on the domain name of this site, you’ve probably already guessed that I’m a fan of Xamarin.Forms (XF). However, the utility of Xamarin as a mobile development platform is a highly debated topic online. In my opinion, the answer to the question posed in this title is highly dependent on your situation. I know, I know, the answer “it depends” is annoying and probably not what you were looking for. But I really think in this case a one size fits all answer is a very poor idea. I’m not going to spend any time on the technical details of benchmarking Xamarin vs. other mobile platforms. In my experience, this isn’t really a huge factor seeing as how Xamarin is at least comparable in performance to native solutions (here’s a post that goes into a lot of detail for those interested). I’m more interested in viewing time invested in Xamarin through the lens of Return On Investment (ROI).

Disclaimer #1: I’m going to be talking specifically about using Xamarin.Forms. I haven’t developed anything specifically targeted to only Xamarin.Android or Xamarin.iOS so I can’t really give a strong recommendation to either.
Disclaimer #2: My background is in .NET so take my perspective on these topics with a grain of salt. While I’m not a .NET zealot, there are certainly downsides to using Xamarin.Forms I might be overlooking due to my familiarity with the tool set.

Let’s Talk About You

The main goal of this post is to attempt to help developers that are stuck in the analysis by paralysis phase of a new side project or side business. You’ve got an idea and you’re itching to get started, but you’ve never tackled a mobile project before. This is the point in which your intent becomes important. Your intent determines your value structure, which in turn helps you to frame what ROI means in your context. Let’s look at some general examples:


  • Goal: Learn something new and enjoy yourself while doing it.
  • Potential ROI: If you’re a hobbyist, more than likely the “return” you’re looking for is enjoyment per hour invested. If you’re already familiar with .NET, XF could be a great choice for you. However, there are several drawbacks (see below) which could jar you out of your flow state and cause you to spend your time investment on annoyances rather than creation.
  • Main Considerations: Ease of use, flow state, time investment required.
  • Verdict: If you’re interested in XF and your background is in .NET, definitely give it a try (see the drawbacks section below for some caveats to this). If your background isn’t in .NET I probably wouldn’t recommend it seeing as how the drawbacks below might ruin the enjoyment factor.

You want to start a business.

  • Goal: Create a mobile app as a product, or as a means of helping to sell your product.
  • Potential ROI: In my opinion, this is where Xamarin.Forms really shines, especially if you have a background in .NET. Even if you don’t have a background in .NET, XF still has some pretty fantastic benefits for budding entrepreneurs. You can build out a clean, testable, architecture with shared business logic AND UI very quickly in XF. The look and feel is not going to be as clean and crisp as native apps, but you can still build a professional, reliable, cross-platform app in a matter of weeks with XF. Considering your main ROI consideration (once you’ve validated your app idea) is time to market, XF is a fantastic tool for entrepreneurs.
  • Main Considerations: Time to a finished product, stability, cross platform.
  • Verdict: XF should be a leading contender for anyone wanting to make their own app. The amount of time it takes to go from blank slate to stable, polished, and production ready application is astounding.

You want to learn skills that will help build your resume.

  • Goal: You want to work on a side project that will build marketable skills for potential employers.
  • Potential ROI: The ROI for this intent is a bit of a mixed bag. The reason I say this is that jobs calling for Xamarin experience aren’t overly abundant. The job posts that I have seen usually require experience using Xamarin.iOS or Xamarin.Android. Because of the amount of heavy lifting Xamarin.Forms does for you, you won’t be able to build very much experience in either of those platforms. With that being said, a huge portion of the work you do in a Xamarin.Forms application applies as general .NET and C# experience which is valuable and marketable. I can certainly say that writing an XF app made me a much better .NET and front-end developer.
  • Main Considerations: Marketability of technology choices, skill transfer.
  • Verdict: If your goal is to gain experience in order to get a job as a mobile developer at a company, XF is probably not your best choice. If you’re looking to pad your .NET/C# experience XF will definitely fit the bill.


I’ll probably make an entirely separate post to talk about the drawbacks of XF in more detail, but I’ll give a brief summary of some of them I encountered below.

  • Long build times- The Xamarin team is working hard to address this (check out the new Hot Reload feature), but this can definitely be a frustrating issue especially for tweaking small UI changes.
  • Cryptic error messages- You will sometimes run into some pretty difficult to parse error messages that get generated by the core layers of Xamarin. Typically, not too painful to work through but can be annoying.
  • Lack of documentation- There is a fair amount of documentation between Microsoft’s official docs, forums, and Github issues. However, there can be a frustrating lack of guidance when implementing non-Microsoft supported packages. It’s difficult to make informed decisions up front about how to implement features like push notifications, OAuth, app badges, etc. due to the lack of documentation.

Hopefully, assessing the value of a technology like Xamarin.Forms through this lens helps you to make an informed decision about what makes sense for your situation. Good luck!