5 steps to an effective app MVP: Validate your app idea without spending a fortune
Or: why most people get app MVPs wrong
I help my clients find out if their app idea is going to be a success before investing significant time or money. How? By carefully designing Minimum Viable Products (MVPs), and testing them in the marketplace.
In this article, I present the rules I’ve built up over 11 years of working with app businesses to quickly identify whether an app idea is a goer or not.
Principle 1: The MVP should be laser-focused on testing ONE hypothesis
Want to build a lap timer app for track runners? Then we have to know if track runners need a lap timer app.
That sounds ridiculously obvious but in the chaos of starting a business, it’s very easy to lose sight of. Everything we do must work towards testing this hypothesis:
Track runners need a lap timer app.
Anything else just wastes time and money. And it’s easy to get distracted, for example:
- Entrepreneur: Can we add a feature that shows the runner’s average lap time too?
Will that help us to test our hypothesis?
Let’s be clear: this MVP isn’t supposed to be an app that the runner can actually use right now. It doesn’t have anything nice-to-have. Those things come later, if the market checks out. Let’s re-read our hypothesis: track runners need a lap timer app. Is average lap time essential to testing this? Probably not.
- Entrepreneur: But our lap timer is different to others. It works out lap time by GPS — no need for the user to press a button when they cross the line.
Well, that’s a bit different. That’s a unique selling point (USP), and MVPs should be all about testing USPs.
So I’d argue that our hypothesis, track runners need a lap timer app, is too loose. We actually want to test: track runners need an automated lap timer app. And so, yes, you include that feature in the MVP. In fact the MVP needs to be centred around that feature.
Principle 2: The MVP isn’t the first version of the app
The guiding principle behind the MVP is to create the cheapest thing possible to test our hypothesis.
What we build to do that isn’t actually a product. It’s not something a user could integrate into their life, or even necessarily something that could work outside a lab setting. I know, I know, what does the P of MVP stand for if not Product? But, in the app world, building and distributing a rounded product is much more work than what’s needed to test a market hypothesis.
So we cut it right, right back.
A public MVP?
An MVP app isn’t posted publicly. Usually we try to be in the same room as the user testing it; if that’s not possible then we at least want to guide them through the process. Feedback is obtained through passive observation or solicited in a highly structured manner.
A cost-effective MVP is just enough to showcase the main feature, but not able to onboard users or log in/out for example. For that reason it can’t be posted on Google Play (for Android) or the Apple App Store (iOS), because partial or non-functioning apps aren’t allowed there.
But we don’t want Random Joe to download the app anyway. His experience and feedback will be skewed by lack of understanding. Later, if the MVP gives positive results, then we’ll spend significant resources on the onboarding process to address this problem — but not now.
Android, iOS or both?
Can we test our hypothesis using just one platform? Usually the answer is yes, since a customer may be using your own hardware. Otherwise we may need to build for both. For many reasons it’s best practice to build apps natively — one app for Android, one app for iOS.
This is what we did for the cosmetics firm Lush for example. Their SXSW house had Android phones running an MVP app which we built. Employees were on hand to guide the user through the process.
Principle 3: Don’t expect to make money from your MVP
Building an MVP is about testing. It isn’t a money-making exercise.
It’s not wrong to keep in contact with your MVP users — they are, after all, a nicely curated list of your target audience, and it may have cost you to obtain them. So they might later become a useful source of early income for your startup, and the existence of the list itself is valuable when seeking investment. But don’t bank your business on their patronage. And definitely don’t spend time implementing a payment system in the MVP: completely aside from breaking all the above rules, it will cost more than it generates.
Furthermore, an MVP isn’t the right place to test pricing questions, and your hypothesis shouldn’t include them. Test only the technical question :
Track runners need a lap timer app
…Not “runners will spend 40€ on a lap timer app”. The latter is a marketing question requiring marketing research, and it comes later once the technical idea has been validated.
Principle 4: MVP code should be thrown away after use
Not only is our MVP not the first version of our app, it shouldn’t turn into the first version of our app either.
This is contrary to what you’ve probably learnt in the Lean Startup and agile methodology, for example, where you see diagrams like this:
We are taught to iterate our builds so that the next is always built using the previous. Build a skateboard MVP, add handlebars to it for the next iteration.
In app development, building something that’s a suitable foundation for future work takes a certain amount of careful architecture, planning and testing. We’re really careful to do this right, because that architecture is carried forward through each future iteration and throughout the life of the product.
But this good architecture takes a lot more time. It’s not worth spending resources on it until you’ve validated your MVP.
Which is why we build MVPs to throw away. There’s no business case to be had for spending 20 days on an MVP when you could build it in 10 days. Remember: the MVP isn’t a first version of the app, it’s a test to determine market traction.
If the market looks good after your MVP test, throw away your MVP and build it properly. Don’t build on shoddy foundations.
Q: Doesn’t this increase the overall effort in building a final product?
A: Yes. Slightly. We essentially build the code behind our MVP twice — once cheaply, and once inside the first version of the app, this time following best practices.
But our concern shouldn’t be for overall cost of the project. It should be for building the MVP as cost-effectively as possible, whilst resources are constrained, so we can test the market as soon as possible.
See it this way: the MVP is funded by you, the entrepreneur. Everything after that is funded by investment. Save your own money!
Principle 5: Don’t use the Agile process to build an MVP
The Agile process is fantastic at building a product for which you don’t know the final destination. During each “sprint” (week/fortnight) you build on the feedback gathered from the last, and the product ends up going in directions you never imagined. It’s not necessarily cheap, but if followed correctly it should build something people want.
But the economics of building an MVP are different. We know exactly what we want to test, and we can plan out exactly what we need to test it.
So we just go ahead and build it, right away. Agile would just slow things down. That also means: don’t solicit feedback halfway through, don’t add new features, don’t rethink things. The only reason we deviate from the original plan is if our initial hypothesis changes — which is to say, if the business idea itself changes.
Once the MVP tests out in the marketplace, future development can fit nicely into your Agile process.
How long should it take to build a simple MVP app on Android / iOS?
Between 1 and 4 weeks, depending on the complexity of the hypothesis we’re testing. If it takes longer than, say, 8 weeks, then the economics of a discardable MVP may not balance, and we could be better off just building the first version of the public app. But more likely we just need to refine the hypothesis question.
How much should an MVP app cost?
Between about 3,000 € and 10,000 € with a good freelancer; a little more if you want the wider support afforded by an agency.
That may sound like a lot, but apps are expensive to build, and our aim is to save significantly on that cost. The first version of your app will likely be upwards of 30,000 € — potentially an order of magnitude more. And large businesses will spend substantially more even than this.
To conclude
An app MVP should test a single technical hypothesis, like “runners need an automated lap timer”. It should include the USP of your business and nothing else. Don’t try to test marketing questions, such as pricing.
Test the MVP with a curated audience; don’t try to make it public. An app suitable for public use (including onboarding and explanations) would be significantly more expensive to build.
Discard your MVP app’s code after use. It should be built as cheaply as possible — not as a foundation for future enhancements. Likewise it should be built quickly, without using processes like Agile.
I hope this has been helpful! As always please add comments/questions below, or directly to me on LinkedIn.
Hi, I’m Tom Colvin; I help build and grow app businesses. I’m a Google Developer Expert in Android with experience launching literally hundreds of apps. I’m available as a freelance Android developer or via the mobile app agency Apptaura which I co-founded.
