Mobile First: Guidance or Dogma?

If I had a dime for every time someone told me, “You have to build mobile-first”, I would be so comfortably well off that I wouldn’t care about building mobile or web applications at all. I would be sipping my favorite drink on a beach.

Firstly — what is “mobile first”? This definition also varies, but mainly it refers to the notion that smart phones, tablets, and other mobile devices are the primary means of people getting work done or using your application or service.

What it does not mean — and I will explain this shortly — is that the first lines of code you write for your application are for iOS or Android.

Having spent twenty years writing software, one universal truth about development and architecture that I have learned is that there is no such thing as a universal truth. One pattern, one guideline, one rule cannot be applied to all situations. There is no One Ring of software patterns to rule them all.

This is the case for the “mobile first” mantra as well. There are situations where it makes perfect sense and situations where I think it could be a costly mistake, but it certainly does not apply to every application.

Let’s say you’re an enterprise and you’re planning on creating a new service that you want to offer from mobile devices. Surely mobile-first here seems like the right way to go. But again, mobile first applies to the assumption that your primary consumers will be on mobile devices. It does not mandate that the first client code you write be iOS or Android.

You design your architecture so that you know it is built to support mobile devices. This means you need to plan for extremely high availability, super-fast responsiveness, and high concurrent volume all on your back end.

In the world of iterative, agile development, an MVP (minimum viable product) is the smallest piece of functionality that vets an idea or concept. A lot of people confuse MVP with alpha version, and that can cost people time, resources, money, and ability to react to changing specs, designs, and requirements.

Let’s walk through a hypothetical. Let’s say you’re building a game. You’re on board with the mobile first idea, so you know the game is going to be used primarily on iOS and Android. You haven’t even thought about whether you’re going to support a web version of this game. You’re an independent developer so you lack the time, resources, and money of a big enterprise to devote to spinning up parallel development teams. You’re going to do it all yourself, like a boss.

Here’s Plan A (what most people think “mobile first” means): Fire up your favorite iOS development tool (likely Xcode) because you know more than 75% of your potentially paying customers are on iOS. You spend the next 6 months of your spare time cranking out ridiculous amounts of mobile code, you create your back end, you build it all. If everything works out perfectly, you’re done and you release 1.0 of your game, make millions, quit your day job, and retire. Reality goes something more like this: about halfway through your development, you hit some aspect of the system that doesn’t work for you, and you need to gut the whole thing and rebuild. You toss over 75% of your iOS code and restart. If you think I’m exaggerating, ask any indie developer who ever built their own thing from scratch.

Now let’s take a look at Plan B (what I believe “mobile first” means): You don’t touch Xcode yet. You start working on a highly available, highly resilient, fast, scalable backend (which means you might be sitting on top of a PaaS or BaaS provider, especially if you’re an indie dev). Next, you build a gameplay simulator. This could be a console application, or, in many cases, is a hideously ugly web page. Your MVP here is the first unit of testable gameplay. If this thing is fun to play “ugly” or “naked”, then it’ll be even more awesome when you put the bells and whistles on. You can now progressively add gameplay elements until you’re satisfied that you have a 1.0 playable concept. Now think about what happened during Plan A. You hit some moment halfway through where you needed to gut your gameplay and change something that required a course correct. But now, since you’re in “ugly mode” just vetting your gameplay, the course correction is easy to make and you haven’t lost a huge investment in bells and whistles that may no longer apply.

So, to make a really long story short: mobile first means you design and build your overall system with the idea that the vast majority (if not all) of your customers will be using your product from a mobile device. It does not mean that you need to build your MVP as a mobile app. Writing mobile-native code is an arduous, tedious process and, especially if you’re the only one doing it, it can suck the wind right out of you if you have to stop and rebuild huge chunks of your app.

The analogy I used here was game development, but this advice doesn’t just apply to game development. Before you write the first line of code of your giant, mobile-first, enterprise app, ask yourself this question: How can I structure my development roadmap so that I am continuously vetting my concept, and spending my time on the most crucial parts of the app first?