From idea to software: the prototype and the Minimum Viable Product (MVP)

In our previous article on the prerequisites for a successful software project, we explained that insufficient time allocated to testing can also prevent a software project from succeeding. In order to test the software’s key functionalities in a commercial context, it is essential to be clear about what is expected of the software. Requirements specifications that reflect these expectations help to take the project forward from the initial idea.

The differences between a prototype and an MVP

A prototype is a sample of a product. Its greatest strength is its realism, which provides guidance for further development. It is possible to produce several different prototype options on a relatively small budget and within a short timeframe. They are, in fact, cost-effective tools for the entire software development process.

A Minimum Viable Product (hereinafter MVP) is similar to a prototype, but the approach is different. An MVP focuses more on the production process and the market, whereas a prototype focuses solely on the product. An MVP is a “viable” product, i.e. one that works in practice, whereas a prototype does not necessarily have to be.

You can find concise descriptions of wireframes, mockups, prototypes and MVPs under “Our Services“.

The Minimum Viable Product streamlines product development

Before investing huge amounts of resources in the development of new software, it is worth testing the original vision and examining it critically. Does the software serve its purpose, and is there a demand for it? Are investors and other key target groups interested in the added value the software offers?

The concept of the Minimum Viable Product has become well known in the worlds of business and software development. For example, according to the Lean Startup method, a startup should ideally begin with a product that embodies the key characteristics of an MVP. The MVP model is particularly well-suited to startups, as they aim to create something revolutionary and different. For example, a completely new product or service that needs to be marketable to both investors and end users should first be implemented as an MVP.

The idea behind MVP is rapid learning: the aim is to recover quickly from mistakes, and every piece of feedback received from a real-world usage scenario triggers a new learning cycle. The idea is also to eliminate under- and over-engineering, with the aim of optimizing production. In light of all this, it can be argued that an MVP is also a product development process, not just a product.

A practical example of MVP

The aim of the MVP model is to deliver a version of the product in which all the key features are realized to their full potential, even if the product as a whole is incomplete in some respects. The image below illustrates the model using a simple example.

The first line does not follow the MVP model. In the MVP model, the product is not built by developing separate components and then putting them together.

The second-row MVP model involves first defining the product’s intended use and, based on that, building a simple, functional system. The second-tier workflow is a valid MVP model if the minimum requirement is simply to have a roof over one’s head. However, the problem definition determines the MVP workflow: if what is required is a house whose minimum requirements include, for example, four walls and a pitched roof, then a hut, a tent and a caravan cannot be MVP models for that product.

In this case, the bottom row describes the implementation in slightly more detail: first, a house is built that meets the minimum requirements. The intermediate stages are each MVP models, which are used to gather feedback from users and the market. As a result of this feedback, learning and optimization of features, a stylish house emerges that meets users’ needs and boasts excellent features.

A Minimum Viable Product is often a sensible investment for a project

The MVP model and prototypes can be used in the same projects, allowing us to benefit from both. They are therefore not mutually exclusive. A prototype can be produced very quickly, and is usually essential for the project to move forward. 

In smaller software projects, simply creating a prototype may be sufficient if market testing does not fit within the budget or is not considered necessary. In larger projects in particular, however, an MVP can be more effective at winning over consumers and investors, as it also functions more clearly in practice than a prototype. 

Of course, a Minimum Viable Product consumes resources, but it is often a sensible investment for the project. In the best-case scenario, an MVP minimizes the overall costs of software development and gets the product to market more quickly. If it becomes apparent that the MVP is not meeting its objectives, not all resources will have been wasted on software or a product that does not work.