Mobile MVPs in Minutes

“If you’re taking more than a day or two to create a Mobile MVP, you’re highly likely to be doing it wrong.”

I’ve been talking a lot with potential entrepreneurs recently, and the conversation often goes something like this:

Them: We’re a new startup, going to do a mashup between, thatter and instatheother.  We’ve been working on our site for the last three months and we’re hoping to launch real soon…

Me: Three months? Waaaaaaaa??? Show me your product already.

Them: Well… err… the backend isn’t quite finished so the mobile app is just a demo right now…

Me: *facepalm*

Credit where credit is due, at least they have a demo while they’re waiting, but come on… three months is a lifetime.  Let’s cut to the chase – unless your product is solely a website or middleware layer, your backend is slowing you down.  Like an elephant riding a bicycle up a hill, you are wasting your own – and quite possibly the people around you’s – energy and time.

To clarify this, in the vast majority of cases – a Mobile App does not require a fancy backend.  In fact it most likely does not require anything that does not support.  How much does your backend engineer cost?  $ or % I bet it costs you more than would…  Up to 1 million API requests/month for free, plus 1 million push messages.  Free as in beer – that’ll get you through a whole heap of customer discovery before you have to pay anything at all!

So here it is – get your Mobile App MVP done in a day, or at max a week, but preferably less.  I’ll be giving a presentation at Beijing BarCamp on 21st April where I’ll create one in my 10 minute time slot.  Half that time will be explaining what I’m going to do and why – so technically that will be an MVP in 5 minutes…

“But… how?”

Oh yes, I meant this post to be more useful than a simple rant…  Here’s what to do.

  1. iOS First.  The iOS toolchain is very mature, and extremely fast for getting stuff done once you’ve realised that coding ppm != productivity.  The sound of your keyboard may be reassuring to you, but in the same way that brownian motion is not moving the petri dish, it’s a crutch.  Dragging and dropping View Controllers, UI elements and connecting them directly to your code is all silent & ninja-like using my trackpad…
  2. Speaking of iOS – the following are your friends: UIStoryboard, CoreData, Parse.framework, Google Analytics.  Don’t argue.
  3. UIStoryboard – forget creating multiple NIB files, and then hardcoding their filenames in initWithNib: – storyboard forces you to see your UI as it develops, and it’s fast.  Coding your UI by hand still?  Go to the room next door, there’s someone waiting.
  4. CoreData – Designing your App around your Data Model is a great way to get started as you’ll find your inconsistencies really quickly.  I’ll save this for another post to go into more detail, but all the features you need can and have already been modeled.  Probably you’ll find all the relevant patterns on
  5. Parse.framework – I’ve not found anything that beats Parse for development and deployment speed.  Want to do a social sharing app?  Parse is your friend.  Cloud sync? Yep.  Push messages?  Yep.  You can even do real-time IM if you think about it… And it would be perfectly acceptable for an MVP.
  6. Google Analytics – What’s the point of doing an MVP if you’re not going to test your assumptions?  Google Analytics with some simple Macros can be dropped in so easily that it’s irresponsible to deploy an MVP without it.

Deploying to iOS5+ only is perfectly acceptable at the early stage.  Your iOS4 holdouts most likely aren’t going to be early adopters – right?

So, with those tools at the ready, take the following steps:

  1. Define your product – what does it do, for who, and why?
  2. From your product definition – define your data model.
  3. Also from your product definition – define your UI flow.
  4. Finally, define your assumptions.

Now, you’re ready to get started:

  1. Take your data model and build your CoreData model around it (if you don’t need Parse) or your Parse Object model.
  2. Take your UI Flow and make your UIStoryboard
  3. Take your Assumptions and extract your analytics.

Now connect the dots with the minimum amount of code needed.  Don’t worry about performance, block the main thread all over the place, just get it all working.  Now go and test it before you unleash it on your family/friends/coworkers!

Look forward to your comments and feedback below – I’ll make another post in this series before too long!

About ikuramedia

ikuramedia - The App Specialists


    1. ikuramedia

      Hi Gerard,

      Thanks for listening to my talk, and for your insightful response.

      I feel I should clarify a couple of points – firstly, I’m advocating early stage startups to not hire a Backend Engineer… A CTO / Mobile Developer should still be part of the team in my opinion.

      Secondly, the backup / maintenance aspects of Parse deserve some clarity. Their maintenance schedules are designed to be non-invasive, so your uptime should not be affected. Getting a backup of your data is super simple as well – you can export a JSON document of your entire database with a single click on the admin interface. This helps to mitigate the ‘financial’ scaling problems because you’re not locked into their BaaS too much. That’s another reason why I’d avoid too much CloudCode even though it’s really powerful – it will make migration to your own hosted service much tougher.

      Totally agree with the performance / location issue – I’d love to see‘s stack hosted on a local cloud…

      Will check out BaasBox – looks like a worthwhile project, thanks for the headsup!

    2. Gerard Braad

      Getting a backup exported to JSON when you have a large set (totalling more than several hundred of megabytes) is not an ideal solution. I also believe a team should consist of the technological knowledge, just often believe the CTO is not the right person to hire so early. It is a loaded title… often what you need is a Technical Lead. From personal experience I can tell startups haven’t defined their own path completely. This person would actually be bothered with day to day task which are part of a devops or a PM. It is often better to seek consultancy first than offering a CTO-level of person equity. It of course also depends on what your product would be.

  1. Pingback: Beijing Barcamp | ikuramedia

What do you think?