Mobile MVP vs. Web MVP

And why you shouldn’t build both

“It is our choices, Harry, that show what we truly are, far more than our abilities.” — Albus Dumbledore

The MVP concept — contradictions built in

If someone would plot a statistic of the words most spoken by early stage startups, I’m betting MVP would be high up in the list.

“The Minimum Viable Product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” — Eric Ries

Or, in other words, the smallest thing you can make in order to test your product market fit. Simple, right? Yet deceptively hard to implement.

When you’re actually making a product, how do you know which features are in the MVP, and which are out? For example, while building dumpstr (our app to simplify knowledge management to the extreme), one constant point of debate was whether to add a “todo list” feature. Is it a feature consistent with dumpstr’s philosophy? Do we want it in? Will our users forgive us for not having this feature? Won’t they all just run away to the competition?

One equation with two variables

When you first start building an MVP you have two main variables to consider:

• Your market
• Your product

Changing the MVP can affect the market, and going for a slightly different market will change the MVP.

For example, in dumpstr, adding a todo-list feature changes the product just enough to also change the target market — from people in want of knowledge management as a place to capture micro-documents, to people that prepare shopping lists or list their todos for tomorrow (possibly a much broader market).

But putting the actual features aside, you might, like us, inevitably reach this tough nut: “Shall we start with a mobile app, or a web app, or both?” Let’s make a shot at cracking it.

An MVP should never include a mobile app and a web version

Why? Simply because it takes too long.

Obviously, building a native mobile app is hard work. It is easy to overlook a few of the reasons, especially when you first try to estimate the effort, just to name a few:

• It’s a separate code base, that needs to be maintained and source controlled
• Publishing to different app markets takes time and know-how
• Different code testing frameworks
• Testing on hundreds of different devices
• Every new feature you decide to add has to be implemented twice
• Depending on your security scheme, security features might need to be implemented separately for mobile authentication

The hybrid app illusion

“But what about Phonegap?” Write in html5, and get a native mobile app on all operating systems!

But this is an illusion.

It may save you from writing both Android and iOS apps, but it can never be the exact same code as your web app. It’s just too different. And all the overhead of testing, maintaining, and supporting is still there.

It’s not necessary

Again, the purpose of an MVP is to get the product out there as fast as possible to early adopters, and test if it justifies actually building it. Getting both a web and mobile app to your early adopters inherently contradicts “as fast as possible”.

Mobile App or Web App — how to decide

Everyone’s favorite answer: it depends.

Depends on the product function as you first envision it. Depends on your target market as best you can define it in that early stage.
Think about the one main use-case of your product, and if this is mobile usage, choose mobile. Otherwise, web.

A quick exercise, fill in the blanks:

What if _______ (your app here) was only a _________ (mobile/web) app?

Mobile-Web is not not sexy

If you gave it some thought and chose to go web-MVP first, that probably means that mobile use cases are intended to cover crude usability on the go (viewing data, minor actions, etc.) If that’s the case, give them the ability to use your product on a mobile browser, they might forgive you not having a native app. And it might be good enough for testing your mobile use-case.

With today’s responsive frameworks such as bootstrap and installable web apps in Chrome for Android, getting a reasonable mobile-web version of your app is quite easy, and is worth doing.

Why we chose web (desktop and mobile)

When making dumpstr, we knew it was a productivity tool, and as developers, we mostly work on our computer.

We had to resist the burning urge to make a native app (which we actually made, and then decided to discontinue for the moment), as it was taking too much time away from what really matters — getting users and feedback for our main use case.

We did put a reasonable effort into making dumpstr responsive and functional in mobile browsers, and it’s been a great return on investment.

Get out there!

To sum things up, your goal is to get out there with an MVP as fast as possible! In most cases, you shouldn’t do that with a native mobile app and a web app. Choose. Unless the main use-case is predominantly mobile, We recommend you go for web, with a nice looking mobile-web version that works in mobile browsers. And then the real fun begins — getting users!