MVP calculator
What Platform Will You Use?

For a new product initiative, it is best if you can focus on one platform for the MVP and then later launch additional applications to further your market reach. Depending on your industry, you will likely choose between the following platforms when making your decision:

WEB

Ruby on Rails, Python/Django, Node.js, you name it

MOBILE

iOS/Android

User Roles

At the core of the “lean startup methodology” is determining the hypothesis that exist for each key constituent of the product you are building. The complexity of an MVP is correlated to the number of constituents that you are aiming to produce value for.
Consider having a marketplace product where you have sellers and buyers. If you are trying to figure out the value proposition of the “buyers”, it will likely be influenced by the “sellers”. A product like this will be more complicated than an ecommerce product where there is only a “buyer” constituent and your company is selling the product, thereby constraining the variables. Keep in mind that an MVP does not need to address all constituents on product launch. In fact, many MVPs will focus on a smaller scope of problem to start with and then expand once the core problem has been validated. Your long term goal may be to create a marketplace, but your MVP may be a limited seller offering to validate demand. The key question we can help answer is what is the best approach for your industry.

1 user

The product involves a single core user type (i.e. if your company sells a product directly to end users or your company generates content for an end user)

2 users

3 or more users

This is likely not an MVP anymore, but we can still help

Architecture

As a product scales, many prototypes get scrapped or refactored because of poor architecture at the foundation of the application, a condition known as “technical debt”. The longer this debt persists, the more costly the refactoring effort becomes. Running a startup is a balancing act of deploying capital for short term and long term return.
While having a qualified CTO will help insure that your product is going to be extendable for future iteration, you may choose to invest more upfront in making the architecture scale for when you need to add a secondary application.

Monolithic Application

A single application. While the code will be well documented, the codebase will not be abstracted leaving the effort for future development

Backend API

By abstracting the core functionality into an API, it makes the cost of future application development less expensive and easier to perform with another development team

Payments

Anytime a product involves the transfer of money, the complexity immediately increases. Payment integration adds complexity because you can’t control the users you will be attracting and you need to protect fraudulent behaviour which can manifest in many different ways. Most MVPs don’t need to monetize from day 1 to prove out the value proposition and this is what we recommend for the majority of companies:

No Payment

Safe and easy

Fixed Payment

If the core question you are trying to answer with your MVP is whether users will pay for your offering, we can build the supporting infrastructure at additional cost

Recurring Payment

Software as a Service or (SaaS) business models may require upfront payment infrastructure as well

Basic

A polished, intuitive application using standard design templates

Custom

In certain cases, it makes sense to have a branded design experience which involve additional design resources

Your MVP estimate

Based on our experiences building a similar minimal viable product, we would advise that you allocate the above budget to pursue your MVP goals. To learn more about the time required to build an MVP or to receive examples of other MVP's we've built, get in touch with us below.