Minimum Viable Product Calculator

SVSG follows a lean startup approach to product development. As part of this approach, development is broken down into weekly sprints. After building many MVPs for organizations of various sizes, we’ve found the following key components to be useful when estimating the weeks of development effort necessary and associated cost of any initiative.

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 Web
Ruby on Rails, Python/Django, Node.js, you name it
Mobile Mobile
Desktop Desktop
Other/Custom Other/Custom
Are you building an embedded hardware device? An online video player? An autonomous vehicle? This probably won’t be a standard MVP, but we can help.

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... more »
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 1 User
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 2 Users
2 Users
The product involves 2 core user types. (i.e. a marketplace with buyers and sellers)
3 or More Users 3 or More Users
3 or More Users
This is likely not an MVP anymore, but we can still help


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... more »
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 Monolithic 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 Backend API
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


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 No Payment
No Payment
Safe and easy
Fixed Payment Fixed Payment
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 Recurring Payment
Recurring Payment
Software as a Service or (SaaS) business models may require upfront payment infrastructure as well

Design Effort

Many companies confuse UI, UX and Visual Design. For a nuanced explanation, consider the following excellent resources: ( “UI vs UX: What’s the Difference?”, “What's the difference between UI and UX design?”). While many MVPs need a specific UX, its not always necessary to have a custom UI. In fact, most MVPs can be built with a polished UI by using tools like Bootstrap which greatly reduce the design effort and associated cost.
Basic Basic
A polished, intuitive application using standard design templates
Custom 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.