Building a true mobile MVP

Ever since we started App & Flow, we’ve met with a lot of teams looking to build their mobile products. Some have a clear idea of what needs to be done: wireframes are ready, features are well mapped out, they have their domain and Slack channel ready. It’s easy to get excited, you finally found your unicorn. Users will be able to organize playdates for their dogs. It will use geolocation to find other dog’s owner near you, and we’ll build some AI to determine if the dogs will get along. When the playdate is over, we will push them products that might interest them: collars, frisbees and kong toys. We also want our users to add each other as friends, and have some favorites. And also… and it never ends.

It is normal to get excited, but it is also important to take a deep breath, take a step back and think about what problem you are solving. You might think you are solving a problem for dog owners (and maybe you are!), and the best way to find out is to build out an MVP. Sure, the idea of having a friend list, favorite playdates and geolocation sounds great, but those three features will be completely useless if no one is using the app. And what if people started using the app, but instead of geolocation they would have preferred to have a directory of Dog Parks shown on a map view? You would have spent time and money building a feature that people do not want instead of building something truly useful. If you build something that truly solves a problem, even if there is not a lot of features, and even if the design is not fancy: you will have users.

First step: Define the solution you have for the problem you are looking to solve.

As a dog owner, I have a hard time finding friends for my dog. Maybe I am not comfortable with dog parks, maybe I would rather have my *insert breed* play with another *same breed*. My solution is to build an application to find the perfect play date for my dog. The core idea is simple: connect with nearby dog owners and organize play dates. No AI, no friends list, no social feed. We’re building an MVP, so we’re focusing on the core problem.

Second step: Choose the right tools.

Alrighty, now we have a clear idea of the problem we are trying to solve, and we believe we have a pretty good solution. However, we didn’t build anything yet. Choosing the right tools is as important as defining your problem/solution. Now we need to build the thing! Whether or not you are on a tight budget, nobody wants to waste money. When building an MVP, we want a cost effective solution that will also allow us to accelerate development speed, reducing it’s cost and easily and affordably scale when (not if 😎) when we need to.

Expo

Expo is a toolchain that allows developers to build a mobile application just as you would using vanilla React Native, but without having to open XCode or Android Studio. That means your team can focus on JavaScript and only JavaScript, no messing around with native modules. With Expo, the developers can quickly and efficiently build a mobile product using Expo’s multiple modules, saving you time (and money). Expo’s support is as top notch as their team, their forums is an excellent place to get help if you encounter any issues or have general questions.

AWS Mobile/AWS AppSync/AWS Amplify

Back in November (2017), Amazon unveiled a new product called AppSync, which alongside DynamoDB could be qualified as a backend as a service(BaaS) to compete with the likes of Graphcool and Firebase. You can picture a BaaS kind of like ordering food for delivery: you pay a little bit more and make some compromises for the convenience. Even before AppSync, BaaS were a good option for an MVP. It reduced the upfront cost of having an application developed by allowing the team of developers to have a reliable backend up and running faster than building one from scratch. The problem was that when your project started to grow, the scaling cost associated with those services would often be quite high, and most often than not teams would then switch to a custom made backend. But now with AppSync, you have the best of both world. And to top it all off, it uses GraphQL! Once you get to a point where costs are a problem on AWS, it means that you and your company are in a pretty good spot (At least, growth wise!).

Auth0

I do not have any hard statistics on this, but I think it is reasonable to say that most applications these days requires the users to authenticate themselves. There are a lot of dev tools to make the process of building an Authentication system easier such as Passportjs (which is supported by Auth0). But in the optic of an MVP, we want to move fast and validate our idea as soon as possible. That is when Auth0 comes into play. Auth0 is “Authentication as a service”, it allows us to quickly implement an authentication system in our application which is not only super convenient, but also probably more secure than if you were to roll your own. In addition to that, most people are tired of creating an account for every service and having to remember hundreds of password, which is why we almost always have the option to “Login with Google” or “Login with Twitter”. Adding such an integration with Auth0 is literally a one click deal. The downside of Auth0 is the same as similar services: when your user base grows, the cost associated to the service while scaling can become an issue, and at that point you might want to start thinking of implementing your own authentication system. But again: we build MVP’s to validate an idea, to see if there is really a need or interest in what we are building. We want to move quickly, reduce cost and get it out as soon as possible, which is why we believe Auth0 is a great tool to use when building the V1 of your product.

Conclusion

Every project we build is different, every team behind those projects is different, but the process of building a first version of a product is often pretty similar. There is no “one size fits all” solution when it comes to building software, and some of those tips might not apply to your situation, but I’d like to think that the general idea can. One example of a situation where you should not follow this approach is if you want to launch a product to compete with already well established solutions. In that case, in order to convince people to switch to your offering, you need a product that is widely superior to the already existing solution. A product like Discord, who wanted to compete with Skype/Ventrilo/TeamSpeak, was vastly better than any of those solutions for gamers (and other communities as well, we use Discord at App and Flow!) A little better won’t be worth the “switching cost” for your potential users. But this is a whole different topic!