Continued from Part 1 As App Creators, we believe in keeping our tools sharp and exercising our creative passion for solving real world problems with Mobile Apps. So with our...
“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 this.io, 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.
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 parse.com does not support. How much does your backend engineer cost? $ or % I bet it costs you more than parse.com 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…
Oh yes, I meant this post to be more useful than a simple rant… Here’s what to do.
- 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…
- Speaking of iOS – the following are your friends: UIStoryboard, CoreData, Parse.framework, Google Analytics. Don’t argue.
- 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.
- 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 dbpatterns.com.
- 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.
- 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:
- Define your product – what does it do, for who, and why?
- From your product definition – define your data model.
- Also from your product definition – define your UI flow.
- Finally, define your assumptions.
Now, you’re ready to get started:
- Take your data model and build your CoreData model around it (if you don’t need Parse) or your Parse Object model.
- Take your UI Flow and make your UIStoryboard
- 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!