What to include in an MVP: the first version of your product

An MVP (minimum viable product) is the smallest version of a product in which a user from outside the team can complete the whole core process. It tells you whether anyone wants to use the product and, ideally, pay for it. What to include in an MVP: one complete process, the accounts and roles that process needs, a simple admin panel and data on how the product is used. Reports, automations, extra roles and integrations built just in case can wait. Below we show how we draw that line, using two products we built: INVENTA Licenses and Offer Exchange.

How do you find the core process of a product?

Before you start listing features, write one sentence: “User X does Y to achieve Z.” Everything needed for Y goes into the MVP. Everything else goes on the “later” list.

Two examples from our projects:

• Offer Exchange: a company sends a request for quotation to a group of sales representatives, collects their quotes, compares them and places an order. That is the whole process. Each sales representative receives a unique link to the offer form by email.
• INVENTA Licenses: a distributor gives a client a time-limited licence, and the client signs in to the VR application. The application checks the account and the licence through a REST API (application programming interface). Without this chain, the VR applications could not be sold under licence.

Look closely at the link for sales representatives in Offer Exchange. It is a good model for thinking about an MVP. Before you plan sign-up, a profile and a portal for the other side of the process, check whether a form at a unique address would do. The other side then gets exactly what it needs to respond, and nothing more.

Scope of the first version

Area	In the MVP	Can wait
Core process	complete, with every step	rare variants and exceptions
Accounts and roles	only the roles the process cannot work without	roles added just in case, detailed permissions
Admin panel	managing accounts and basic data	reports, charts, exports
Payments	if you are testing whether customers will pay	automated discounts, multiple currencies
Notifications	email at the key moments of the process	SMS, browser notifications
Integrations	only those without which the product makes no sense	integrations in case customers ask one day
Measurement	basic usage data	detailed analytics

What the first versions of our products looked like

Offer Exchange started with collecting offers and the comparison tool. The other features, including orders and paid subscriptions, came in later versions. INVENTA Licenses started as a module without a graphical interface that talked to the VR applications through the API. The portals for clients, distributors and the administrator came later. Building the first version took up to 6 weeks, including meetings with the client.

Not everything in the first version worked out. At first, the Offer Exchange comparison tool only compared the totals of whole offers, not the prices of individual products. That was a wrong assumption, not a deliberate simplification. The lesson for an MVP: before you design the main feature, check with a few users how much detail they need to make a decision.

How many user roles does an MVP need?

As many as the business model requires. Each role means separate views, permissions and tests, so it is one of the main cost drivers. We explain this in our article on what a custom web application costs.

INVENTA Licenses has three portals (client, distributor and administrator), and each of them is justified here. Licences are sold by distributors, so they need to create client accounts and assign licences. Clients need a place to see their applications and licence validity and to request new licences. The administrator manages everything. If the product were sold directly, the distributor portal would be unnecessary.

Should an MVP include payments?

It depends on what you want to test. If the main question is “will anyone pay for this?”, payments belong in the first version. What people say in surveys tells you little.

Offer Exchange shows a model that works well for this. The application can be used free of charge, with monthly limits on the number of requests, recipients and products. One of three paid subscriptions raises those limits, and Stripe handles payments and invoicing. Users can start for free, and the moment they reach a limit is a natural point to decide on a purchase.

If payments are not what you are testing, invoicing the first few customers by hand is enough at the start. You can add a payment gateway once you know which pricing model works.

Technology in the first version of a product

With an MVP, you often hear “we’ll build it fast and rewrite it later”. That rarely happens, because after launch a rewrite competes with the new features customers ask for. Besides, the MVP collects customer accounts, licences and data that you cannot throw away.

That is why we build MVPs with the same technologies as full products: Next.js, React, TypeScript and PostgreSQL (and .NET Core in Offer Exchange). We deploy them in Docker containers behind an Nginx server. We cut the scope, but we do not cut corners on the foundations. The data model, permissions and database backups are done properly from the start.

A few things we watch in a first version:

• a data model with room to grow where change is expensive, for example a licence assigned to an account and to a specific application rather than to the account alone,
• a versioned API from the first release if applications installed at customer sites use it, like the VR applications in INVENTA Licenses,
• an admin panel good enough to serve customers without a developer,
• usage measurement, because without it you will not know what to develop after a few months.

Read more about how we run these projects on our page about SaaS and MVP development.

Plan for the next versions

The “later” list matters as much as the MVP scope. Write it down straight away and, for each item, note which signal from users will make you build it. After launch, you then develop the product based on what actually happens, and the loudest request no longer sets the direction. How we work through the later stages of a project is described in our article on the custom software development process.

If you are building your own product and wondering what to include in the first version, get in touch. We will help you define the MVP scope and quote for it in stages.