Building a Minimum Viable Product (MVP)

It’s entirely possible that you’ve heard the term ‘MVP’ or ‘Minimum Viable Product’ as it’s being casually thrown around quite often in regards to building web applications. That said, I noticed that knowing about it rarely goes together with understanding it and its importance. In order to rectify this, I want to walk you through the subject and extend the definition with some examples of practical applications. Let’s start with… the definition.

What is a Minimum Viable Product or MVP?

I find the definition provided by Wikipedia to be beautifully simple and accurate at the same time:

A minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development.

Like I said, simple yet to the point. As often happens, with simplicity comes a lot of misunderstanding. In case of this definition, there are a few places that can result in problematic interpretation. These are my favorite:

“With just enough features” – believe it or not, it’s almost certain that you’ll think that the first version of the product must be more complex than what we would suggest. That’s mostly because owners want to…

“Satisfy early customers” – yet, people who should be using the MVP version of the product are not really customers. Typically, these come from highly curated lists of interested potential customers that signed up in the Proof of Concept phase or are involved through different channels, but still super-hyped about the product.

Why is it beneficial to start with Minimum Viable Product?

It’s simple, MONEY. When you start thinking about the specifics of the application you’d like to build, you will start to find more of more “must-haves” that can make your future customers happy and eager to convert. This is good; you should always keep a backlog of things to verify, but at this early stage, the result is that you’d need a huge budget (we’re talking at least 5 figures) and many months to build the complicated system without any indication how well it will be received by the market. When you take into consideration that the success rate for startups is about 5-10%, are you really willing to take the risk?

The MVP concept is aimed at minimizing the initial investment, shortening the time to market to weeks (instead of years), and hugely reducing engineering waste to implementing features that no one is interested in actually using.

There’s also a very important aspect of this process. It enforces the owner to answer very uncomfortable questions such as:

• Which feature is the most beneficial for my users? What problem am I aiming at REALLY solving for them?
• What indication do I have to claim that the such a product is desired by the chosen target group? Was there a Proof of Concept performed for the idea? We humans are so good at convincing ourselves that we have conceived the best idea ever.
• Is there a competing product already on the market? If so, what’s better for what I want to build? What are the issues with the currently available solutions? Interestingly, the fact that there isn’t one rarely indicates a niche – you need to consider the lack of interested users in the past and consider why.
• What is the target users group for the solution? It’s super rare that something is “for everyone”.

This all sounds like a lot of work before you’ve even built anything. It is, but look at it this way: It’s better to start small and make sure that your idea has merit than jumping into a huge build with nothing more than a feeling. I see it time after time; how the initial idea changes, molds into a different shape or even dies out, replaced by something else that emerged from the experience gained from this early, simplified work.

How does Nopio work on building a Minimum Viable Product?

Every project is slightly different, but there’s a common path that we walk with every customer that is looking to build an MVP. The differences are mostly due to the work that has been performed earlier or the complexity of the domain/subject we’re working with. How do we build a MVP? Our process looks as follows:

Project Discovery

This is when we spend the time on:

• Learning about the domain the project relates to. It’s essential for us to understand the subject we’re working with. It’s so much easier if you can discuss the subject with someone else who “gets it”.
• Engaging you into discussions that allow us to understand the concrete problem and solution you’re building. This is how we can help you decide the core value you’re offering to your target group.
• Pushing you to understand and answer the foundation questions listed above.
• Planning the elements of the system that will be required in order to create technology that implements your solution. This is needed for us to create a tech team to handle the project effectively.
• Running a Proof of Concept process if it hasn’t been done already. We help you to create the marketing materials and set up a marketing campaign to reach the audience
• Planning on visual identity if one is not already created. We walk you through choosing the color scheme and generic logo characteristics. We’re not looking to do the whole branding process, but to know the bare minimum for the identity creation.
• Optionally, we can help you to create the whole business strategy for your project, but it’s usually a longer and more extensive process than just building the MVP.

Not all of these are required for our involvement, but that’s our role – we work with you toward the overall goal of creating the MVP of your product in the most optimized way.

Design and Development

Armed with the facts gathered from the Discovery phase, we can proceed onto actually following the plan we created. There are 2 main threads for the effort from this phase and we work on them in parallel, but we begin with the design and UX for the features that were chosen to be part of the MVP build. This work doesn’t aim at creating your final look and feel of the application – it’s our best estimate which we expect to change and adapt based on feedback from the initial user group. Because of that, there’s little sense of spending a lot of time on it, just enough to grab the general feel you want to achieve for desktop and mobile users.

Having the base UI/UX designed, our tech team then begins to build the actual technological part of the project. Often I hear that an MVP build should be quick and dirty; while I agree that time is of the essence, it should not be used as an excuse for poor quality. The goal is to find a sweet spot between build time and other factors of the resulting application such as:

• Extensibility – ease of adding new features or changing the existing ones to accommodate real users needs.
• Modularity – since we don’t know exactly if all the initial features will be kept in the app, we design the application code in such way that is easy to turn off/remove unwanted ones.
• Readability – we aim for the application that makes it easy for the new/additional developers to join the team. In order to achieve this, we employ best industry practices such as Behavior-Driven Development and Test-Driven Development.

The whole time we work on the application, we stay in close contact with you constantly in order to keep a feedback loop going, adjusting the solution to incorporate optimizations as we go. We encourage you to use our

In the meantime, we help you to keep the chosen early adopters updated about the progress and hyped about a possible solution to their pressing problem. It’s important that they see progress and feel valued – they are your best source of first-hand knowledge about what you’re building, therefore they are priceless.

Launch Day

This is the moment we have worked so hard to reach. The MVP is finished, it’s been through our and your Quality Assessment, and is proudly sitting on the designated hosting solution, ready to receive the users’ traffic.

At this point, we begin monitoring how the application performs while you walk the early adopters group through the finalized system. We can help you with organizing a webinar or recording instructional videos.

Building a MVP – summary

This is the path we walk with all our MVP builds. It’s about 8 weeks of discussions, planning, designing, developing, testing and advertising. All for the ultimate goal of proving that your project is valuable for the potential customers. This is an exciting first step that we advise all customers thinking about owning a start-up to go with.

Interested in building your own MVP? Contact us!