How to build your Minimum Viable Stack

Editor's note: Solene Maître is Co-founder & CPO at naow, a playful and anonymous app to ask questions to people nearby.

MVS: The Forgotten Son in Product Development

SlidePay <!--more--> When it comes to building an app, most of a team’s focus is on their Minimum Viable Product (MVP). As such, everybody will invariably give their two cents on how to build it: ”What do you really want to test?”; “Who will be you first users?”; “Oh, and can you ship it as quickly, dirty and fast-failing as possible?” And so on.

But behind what the user sees is a powerhouse of code and fancy language to build the core functions of an app.

It’s analogous to the plumbing and electricity in a person’s house—although it isn’t visible, it is paramount to the function of the house. Also referred to as the “backend”, it is the essential building blocks of an app that requires lots of sweat and tears to build, save for the plumber’s crack. Working on our first mobile app at  naow, we quickly realised how much we would have to iterate on this MVP and move around this set of limited features. Exploring options from a UX standpoint meant we had to have a backend that would easily and quickly adapt to these iterations as well. There is no point in having a MVP supported by a coded-from-scratch backend that takes ages to adapt and makes your developer crazy when he hears the word “iteration”. Also, if you already haven’t heard about our lovely startup stories addressing our naiveté, check our our first article on being a geographically lean startup from our CEO  here. So now is time for me to give you a little background on how we built our Minimum Viable Stack (MVS), how much we have saved from it (energy, time, money) for the last 4 months, and why we sometimes found it difficult to convince people of this strategy.

Backends can be built with/without the use of service providers that provide already built functions. While some startups have the resources to take on such a bold undertaking, many of them are often dealing with scarce resources. To this end, building a backend with the use of service providers (referred to Backend as a Service) saves both time and money—something that makes us and our investors happy.

Four months ago, we started building our first prototype (if you follow, the “MVP”)

…a mobile app which allowed users to easily chat with anyone around them, anonymously. We built this app in just one month: 1 week to design the UX/UI and 2 weeks to develop the front-end (what the user actually sees). Oh wait? That’s 3 weeks right? Yes. Because we were then confronted to one single choice to move forward: building a reliable, complete backend in 3 to 4 weeks, or building our Minimum Viable Stack in 1 week with a legos-style approach. As you can imagine reading this article, we chose the latter option. In our case, we used  Parse to store data, build our APIs, and send push notifications. We connected it to  Firebase to allow real chat communications, i.e., if you want seamless chat. This recipe proved to be quite successful in our case since all our users tests were carried out perfectly.

How did we come to find all the right ingredients?

  • I searched on—a great resource for providers who met our needs and a great way to browse services that our app required.
  • I validated their reliability by looking if they had an active community on Stackoverflow, Github or on their own forum.
  • also wanted to see if they would quickly answer a fake email I sent (Firebase did ;=) thank you guys!) and checked if they were no longer running in beta.
  • I tried to reduce the number of providers and make sure that one provider could solve our major problems.
  • I discussed with our developer to see if he was familiar with the language and if the documentation was clear.
  • And I didn’t mind about the providers’ pricing since we already knew it was a temporary solution…

Without this recipe, the iterations and user tests we’ve made so far would have been impossible and our development time would’ve been doubled. Undoubtedly, the technical aspects would have oriented our decisions on the product and eventually killed our vision. Did I mention we haven’t paid a dime yet to any of our providers?

Now let’s move on to convincing everyone about your recipe.

Below are two likely things you may hear from people in the field that you shouldn’t pay much credence to: 1. If you hire a talented developer, he/she will convince you to build the backend from scratch. Of course it’s a real challenge for a developer to build the foundations of your app, this process poses the most challenging problems. Tell them to take it easy, the time will come when they will have to solve these problems. 2. You will be told that backend service providers are too expensive and won’t be able to meet the challenges that your app poses.Those services start to be expensive when you start to have thousands of users. It won’t be an issue when you are an early-stage startup with few beta-testers. Plus, if you are actually quickly seeing Product/Market Fit with accompanying scale issues, investors will gladly start filling up your coffers with considerable cash.

To conclude, although building an app’s MVP is integral to the whole “Product development” process, more credence should be paid to this forgotten son of the Minimum Viable Family! That’s my two cents on building your Minimum Viable Stack (MVS) as a girl CPO. I’d love to have an open discussion regarding this matter, so if you have time to debate, ping me on Twitter  @solenema.

This post was originally published on Medium.