Entrepreneurs Should Not do Mobile App Development

A lot of people want to go into mobile development because they want to make money. But that’s not the right way to look at it. You should be thinking about where you can get up to speed the fastest such that you can offer something valuable to the wider market. As a rule, I think entrepreneurs should not try to dive into the mobile app space unless…

  1. They are experts at mobile app development already, or;
  2. They have the money to hire people who are such experts.

The Why

  1. Mobile is saturated - Everyone thinks they’ll make millions there which makes it harder for people to do so. It’s also a very noisy space, and you’ll keep reading different things from different people talking about how to do different things differently.
  2. Mobile will never be bigger than web dev - By definition the web will always bigger than mobile, because mobile app development is largely a subset of what the web can offer.
  3. Mobile apps can be emulated by hybrid apps - Platforms like Xamarin, Titanium, and PhoneGap/Cordova all allow you to make very rich apps using web development techniques. But you might say: hybrid apps are slow and will never be as fast as native apps. This might be true, but unless your business idea is something specifically for the mobile platform, there’s no point in giving yourself such a hard time (read on).
  4. Mobile lacks control - There are too many platforms and changing APIs. It’s like trying to hit a moving target, it’s just not going to work out very well. Google or Apple can change the API on you, and the next thing you know you’re scrambling to keep your app relevant.

More Reasons

People say that the app space is growing so fast and that it’s huge. But there will always be large markets, why would you confine yourself to a small one when there’s a bigger one that’s still growing? You cannot have mobile without the web.

The goal of the entrepreneur should not be learning Android or iOS development. It is like trying to get across a river by walking in the mud when there’s a bridge already built. The goal of the entrepreneur as it pertains to mobile apps is that he should build and grow his business to the point where he would be able to spend money to hire some developer who’s had to live his life in Android/iOS-land because he chose overspecialization instead of trying to build a business. The entrepreneur would then instruct him to take care of building out the Android/iOS arm of his business where there is a specific market need for it.

Doing Android/iOS is like riding an elephant when there’s a car on the ground beside you. But hey, at least you got to say you rode on an elephant! And I sincerely think there is value in that. Just don’t do it forever.


But isn’t the web saturated too?

Not nearly as much as the mobile market, this is because the web is an open platform and you can always invent your way into new pastures. There’s a whole slew of new protocols that are still undeveloped. You can go develop that, and BAM you have a new slice of the web.

With mobile, you’re locked-in to the platform’s API and if Google or Apple tells you to jump, you have to say “how high?”

But what does saturated really mean?

Saturated - Extreme over-population of a market, causing the inability to sufficiently and expediently define your niche and thus the ability to market your value proposition.

Let’s say you wanted to make an app that allows you to keep track of food expiry. Immediately, you get lumped into the group of “food-related apps” and you’re competing against them even if you are doing something different. Everything is in buckets, because the consumer looks at apps all in the same way.

It’s also not very agile. Say you wanted to clarify how you’re different from these other apps that are food-related. Well, on the web there are a million different ways to do that. With an app, you’re either adding features and changing up your description or maybe simply submitting your app to different blogs.

Well okay, but how can I differentiate on the web as opposed to in the mobile app space?

You can change the page, add an API, you can scrape, you can create bots to do stuff for you. You can link to your own blog. You can provide an e-commerce service or even start an affiliate program of your own for others. The possibilities are endless.

Locked-in API

With little exception, on a mobile app platform there’s usually only one or two specific ways to implement something. For example, when I was working on Android, I found out that there was only one real way to implement a list. Only one way to make a certain type of animation. Only one way to do this and that and everything else. A closed API really sucks, and because it is so close to the hardware, it’s very low level and the code is especially verbose (I’m look at you Android/Java). This is less of a problem with Swift, but it’s still a problem.

At the end of the day, it’s like playing with LEGO instead of cutting and sawing your own pieces of wood and metal to build something that you want.

But there are libraries on Android/iOS that lets you do a lot of those things easily!

Yes but they’re still doing it through the traditional way. They’re still doing it through the traditional API, it’s just abstracted to make it easier for you. Arguably, you can say that about the web too, but it’s at a much much higher level.

To take making a list as an example, I can build something to create a list based off of pure CSS. Or I can do another one that is produced from SVG definitions. Or I can make one in OpenGL. Or I can do all sorts of wacky stuff. etc. etc. And depending on how you want to tweak things, they might all end up performing well on peoples computers, because we have control over how the browser itself interacts with my site.

Final Note

The craziest sh*t is possible on the web, and it’s often a lot easier and faster too. Don’t be fooled by all the rockstars making millions off of apps, they are the outliars. Mobile apps are just a lake while the web is an ocean.

comments powered by Disqus