To build an MVP, a minimum viable product, you start from the question it has to answer, not from a list of features. One group of users, one path from entry to result, and one number that will tell you, after a set time, whether to keep going. Everything that is not needed to measure that number goes on a "not now" list.
The budget for a first version usually gets burned in one of two ways. The first is building too many features before the product sees its first real user. The second is less obvious: cutting corners in places that cannot be fixed cheaply later, such as the data model, permissions or payment handling.
- An MVP is a tool for learning about users, not a cut-down version of the target product. It starts from a hypothesis that may turn out to be wrong.
- The scope is set by one group of users and one path. Every feature the path does not break without goes on the "not now" list, with the reason written down.
- Save on looks, the admin panel, automation and scale. Do not save on the data model, permissions, payments, backups or legal paperwork.
- Set the number, the threshold and the review date before launch, and keep part of the budget for changes after launch.
- Rewriting everything is rarely a good decision. Replacing the code module by module usually pays off better.
What an MVP is and what it is not
Eric Ries, who popularised the term, defined it in 2009 as the version of a new product that allows a team to collect the maximum amount of validated learning about customers with the least effort. The key word in that definition is "learning". It is the effort that should be minimal, not the product. An MVP that works but settles nothing was simply a cheaper project, not an experiment.
In practice, the MVP label covers things that answer completely different questions. Before you ask for a quote, check what you actually need:
MVP versus prototype and proof of concept
| Form | Which question it answers | Who uses it |
|---|---|---|
| Wireframe or clickable prototype | Do people understand how the product works and what to do in it | A few people in interviews, with no real data |
| Proof of concept | Can it be built technically, for example can data from one system be processed in the time needed | The team, nobody outside |
| MVP | Will people use the product for a real task, and will they pay for it | A first, narrow group of real users |
| First commercial version | Does the product work in the wider market, and how should it be sold | All customers in the target group |
Mixing these forms up costs you either way. A clickable prototype called an MVP gives you opinions but no data on behaviour, because nobody actually gets anything done in it. A full commercial version called an MVP eats the budget meant for learning and leaves no money to change direction.
An MVP does not always require code. Some hypotheses can be tested with a page with a sign-up form, or with a service delivered by hand that the customer pays for before any automation exists. Code is needed when the automation itself is the product's value, when the test requires real payments from many users at once, or when a business customer has to connect the product to its processes in order to evaluate it.
Before you build an MVP, write down a hypothesis that can fail
A hypothesis is a single sentence that can be tested and that may turn out to be false. A handy template looks like this: "We believe that [who] will do [what], because [what problem]. We will consider this confirmed if by [date] at least [number] [of whom] do [a specific thing]".
Throughout the article we will use one example, invented for this guide. Imagine a product for small language schools that currently take enrolments by phone and get paid by bank transfer. The hypothesis could be: "We believe that owners of small language schools will move course enrolments to a system with online payment, because keeping track of payments by hand takes their time and causes mistakes. We will consider this confirmed if, within eight weeks of launch, at least five schools take enrolments for a paid course through the system".
The numbers in this example are arbitrary. What matters is that the sentence contains a specific group, a behaviour, a threshold and a date. "We will check whether schools are interested" is not a hypothesis, because it cannot be disproved. There is always some interest.
Every product rests on several assumptions at once: that the problem exists, that the solution removes it, that people will pay for it, that you can reach them, and that the product can be built at a reasonable cost. An MVP should test the riskiest and least certain assumption. If the biggest unknown is whether schools want online payments, there is no point building an advanced class timetable first.
Before you commission the build, talk to a few people from the target group and ask how they solve the problem today and what it costs them. Do not ask whether they would use your product, because almost everyone will say yes out of politeness. Ask about what they already do, because past behaviour tells you more than a promise about the future.
How to build an MVP: one group, one path, one result
The scope of the first version follows directly from the hypothesis. If the hypothesis is well written, most feature decisions make themselves, because for each one you only need to ask whether the hypothesis can be tested without it.
In the example, these are small language schools with a single location, not all educational institutions. A narrower group means fewer exceptions to handle and a clearer result.
The school creates an account, adds a course with a date and price, and sends a link. The student opens the link, signs up and pays. The school sees the list of sign-ups and payments.
For each one, ask whether the path breaks without it. If not, the step goes on the "not now" list.
Anything a person can do for the first few weeks, for example setting up accounts for schools or sending summaries, a person does.
For every feature you put off, note why it is not there and what signal from users would bring it back.
The date is fixed and the scope changes. If something is not ready in time, it drops out of the first version instead of pushing back the launch.
Step six is the hardest, because during the build there is always a feature that seems essential. Every week the launch slips is a week in which you pay for developing the product without knowing whether it is heading in the right direction.
What an MVP should include and what you put off
The "not now" list is just as important as the feature list. It shows the contractor where the boundaries of the scope are, and reminds you during the project that putting something off was a decision, not an oversight. For the example product it could look like this:
Example MVP scope
| Feature | In the first version | Why |
|---|---|---|
| School account and adding a course | Yes | Without it the path does not exist |
| Student sign-up and online payment | Yes | This is the behaviour the hypothesis tests |
| List of sign-ups with CSV export | Yes | The school has to work with this data from day one |
| Email notification of a sign-up | Yes | Without it the school does not know anything has happened |
| Invoices | Issued in the software the school already uses | Invoicing is not the hypothesis being tested |
| Mobile app | No, a website that works on a phone | A browser is enough to test the hypothesis |
| SMS notifications | No | Email is enough for the test, SMS costs money per message |
| Reports and charts | No, export to a spreadsheet | With a few schools, a report can be prepared by hand |
| Multiple locations and teacher accounts | No, but the data model is ready for it | Expansion is likely, so it must not require a rebuild |
| Discount codes and referrals | No | Without traffic you cannot tell whether they work |
| English version | No | The target group for the first version is Polish-speaking |
Note the row about locations. The feature is not there, but from day one the data model assumes that courses belong to a school and a school can have more than one place where classes are held. At the database design stage this costs little, and it saves you migrating real customers' data a few months later.
The most common argument for adding a feature to an MVP is "it's only one day of work". Even if that is true, the feature then has to be tested, maintained and taken into account with every change. It also blurs the measurement: if schools start using the product, you will not know whether online payment or discount codes brought them in.
The same logic applies to choosing between a mobile app and a website. If the hypothesis does not concern features available only in an app from an app store, a browser-based MVP will test it more cheaply and quickly. We described when an app store app is really needed in our article mobile app or PWA.
Where to save in an MVP and what not to simplify
The rule is simple: save where changing things later is cheap, and do not simplify where a later change touches real users' data or their money. A button's look changes in an hour. A data model in which it is unclear who a record belongs to takes weeks to change, because you have to move the data, fix the permissions and check every feature that uses it.
Where to cut and where not to
| Area | Can be simplified | Do not simplify |
|---|---|---|
| Look and feel | A consistent set of simple components instead of polished illustrations and animations | Readability, working on a phone, correct forms and error messages |
| Admin panel | Minimal, with the team doing some operations by hand | Permissions, meaning who can see whose data |
| Data model | Fewer fields and fewer record types | Relationships and data ownership, for example the school as the owner of courses from day one |
| Payments | One payment provider and the provider's hosted payment page | Confirming payments on the server, based on a notification from the provider |
| Infrastructure | One server, no automatic scaling | Backups with tested restores, HTTPS, security updates |
| Integrations | CSV file export and import | Unique identifiers that will let you connect other systems later |
| Testing | Clicking through the main path by hand before every deployment | Automated tests for payments and permissions |
| Legal paperwork | Short, clear documents instead of long ones | Terms of service, information on data processing, and consent where it is required |
Payments deserve a separate word. The browser being redirected back to the store after payment is not confirmation of payment, because the customer can close the browser tab or lose the connection, and the return URL can be opened by hand. The "paid" status should be set by the server once it receives a notification from the payment provider. It is a small amount of extra work, and without it you get orders marked as paid with no money behind them, or paid orders that nobody fulfils.
Legal paperwork is not an add-on for later either. If you provide services by electronic means as part of the product, you must set out terms of service and make them available before the contract is concluded (Article 8 of Poland's Act on Providing Services by Electronic Means). If you collect personal data, and an MVP almost always does, you must provide information about its processing in line with the GDPR. Analytics and advertising tools that store information on the user's device or read it from there generally require the user's prior consent (Article 399 of Poland's Electronic Communications Law). The exceptions include storage necessary to provide the service the user is asking for.
If the product sells to consumers through a website or app, also check the Act on ensuring compliance with the accessibility requirements of certain products and services by economic operators, which has applied since 28 June 2025. As the Polish government's digital accessibility service points out, it does not apply to services offered by microenterprises, but the exemption disappears once the company stops being a microenterprise. Basic accessibility, meaning labelled form fields, keyboard support and sufficient contrast, costs little at the start and much more when added later.
Off-the-shelf services instead of your own code
Not everything in an MVP has to be written. Payments are handled by a payment provider, transactional emails by an external sending service, login can rely on a proven library, and some processes can run in a no-code tool at the start. A rule that works well: buy what is not your competitive advantage, and build what you are testing.
Every off-the-shelf service, however, has three costs worth knowing before you choose:
- The price grows with usage. A per-user or per-transaction fee is negligible with a few customers, but with a few thousand it can become the biggest item in the budget.
- Plan limits. The number of records, automations or API calls can stop the product just as it starts to grow.
- Data export. Logic built in a no-code tool usually cannot be exported, so when you move it has to be recreated in code.
We described the same calculation in more detail in our article admin panel instead of a spreadsheet. For an MVP the conclusion is similar: no-code is a good choice if the hypothesis is about demand rather than the automation itself, and if you assume from the outset that once it is confirmed, the product will be rebuilt from scratch in code.
The MVP budget: building it is only the first part
The most common way to burn the budget is to spend all of it on the first version. The product launches, the first users show what needs to change, and there is no money left for those changes. Yet those changes are the very reason you build an MVP.
Plan the budget in two parts: building a version that will test the hypothesis, and several rounds of improvements after launch, based on what users actually do. If it does not all fit, cut the scope of the first part, not the second part.
This split fits well with different billing models. A first version with a clearly described scope and a "not now" list is suitable for a fixed-price quote, while development after launch, whose scope by definition you do not know, is easier to bill hourly with an agreed cap. We described the differences between these models and the risk on each side in our article fixed price or time and materials.
On top of the build cost come recurring costs that are easy to forget in the first quote: the server, the domain, payment provider fees, the email sending service, paid APIs and security updates. When comparing offers, check that each quote covers the same scope and what is excluded from it. We show how to do that step by step in our article how to read a software house quote.
Keeping the budget under control during the build comes down to a few habits:
- A working version every week. You see progress in a test environment by clicking through the path, not on slides.
- Every new idea goes on the "not now" list. It comes back into the scope only if something else drops out.
- One person on your side makes the decisions. Contractor questions waiting days for an answer drag a project out more than most technical problems.
Every feature added before launch pushes back the moment you find out whether the product makes sense. If the feature list keeps growing and the launch date keeps moving further away, the project has stopped being an experiment and become a build funded on credit against untested assumptions.
How to measure an MVP: number, threshold and date before launch
Before the product launches, write down three things: which number you are watching, what threshold you will treat as success and when you will assess it. Then add what you will do for each outcome. Without these notes any result can be read as encouraging, because there is always some line going up on a chart.
Some numbers look good in a presentation but do not answer the question in the hypothesis.
MVP metrics
| Metric | What it tells you | The trap |
|---|---|---|
| Sign-ups | Whether the product description attracts the right people | Says nothing about whether the product works |
| Activation, meaning the first run through the main path | Whether people get to the value | The definition has to be strict, for example "the school accepted its first payment", not "logged in" |
| Return visits in the following weeks | Whether the product is needed regularly, not just once | With few users, a single person moves the result a lot |
| Payment or a binding commitment | Whether the value is worth money | A free pilot does not answer this question |
| Time to first result | How much friction there is on the path | An average hides the people who got stuck and gave up |
| Cancellations and the reasons for them | What is not working | Without a conversation you know only the number, not the cause |
With an MVP the numbers are small, and you have to account for that honestly. If the product has fifteen active users, one person is almost seven percentage points. A retention chart from a group like that tells you more about specific people than about a trend. That is why, with a first version, quantitative measurement is always supplemented by conversations. It is worth talking in person to every user who dropped out and every user who uses the product more often than the rest.
The most reliable data for assessing an MVP comes from the product's own database. Events such as creating an account, publishing a course or a confirmed payment are recorded by the server, so they do not depend on ad blockers or cookie consent. Browser analytics requires the consent mentioned above and will not see some users. It is useful for finding where people abandon the path, but to assess the hypothesis a few database queries once a week are usually enough.
After launch: extend, change direction or close
After the set time, you compare the result with the threshold. A clean "yes" or "no" is rare, but the patterns repeat often enough that you can map them to decisions in advance:
MVP result and next step
| Result | What it usually means | Next step |
|---|---|---|
| Threshold exceeded, users come back | The hypothesis was confirmed | Review the "not now" list, tidy up the code, plan the next version |
| Many sign-ups, few activations | The promise attracts people, but the path fails or the product does something other than the description promises | Talk to people who dropped off, fix the path, not new features |
| Activation happens, no return visits | The need is one-off or the value is too small | Check whether another group has this need more often |
| They use it but do not pay | The value does not justify the price, or someone else should be paying | Test a different price or a different payer, for example a company instead of an individual |
| Hardly anyone reaches the product at all | A reach problem, not a product problem | Change the acquisition channel before changing the product |
Closing a project after the MVP does not mean the budget was wasted. An MVP that showed the main assumption was wrong did its job for a fraction of the cost of the full product. The wasted budget is the one after which you still do not know whether the assumption was true, because nobody wrote down a threshold or a date.
With an in-between result, a common mistake is to keep adding features in the hope that one of them will tip the balance. If people are not getting through the main path, another feature next to it will not change anything.
When to rewrite an MVP and when to extend the existing code
A first version is allowed to be written faster and less carefully than the target product. Ward Cunningham described this in 1992 with the debt metaphor, which gave us the term technical debt: shipping first-time code is like going into debt, which speeds up work as long as it is paid back quickly. When nobody pays it back, every subsequent change pays interest in the form of longer work and new bugs.
The natural reaction to growing debt is the idea of rewriting everything from scratch. In 2000 Joel Spolsky called rewriting software from scratch the single worst strategic mistake a software company can make, using the example of Netscape, where almost three years passed between the release of version 4.0 and the public beta of version 6.0. The old code had been used and tested, and the fixes for bugs found in it are knowledge that is lost in a rewrite.
Between these extremes is the approach Martin Fowler described as the Strangler Fig Application: new code is built alongside the old and gradually takes over more and more functions until the old code is no longer needed. The product keeps working the whole time, and each stage can be checked separately. For an MVP that has proved itself, this is usually the best route.
Extend or rewrite
| Signal | What to do, usually |
|---|---|
| The code is inelegant, but changes are predictable and do not break other places | Extend it, tidying up as you make further changes |
| Every change breaks something somewhere else, and there are no tests | First automated tests for the main path, then tidying up module by module |
| The data model does not fit the confirmed hypothesis, for example the product has changed its target group | Rewrite the data layer with a migration, the rest gradually |
| The MVP was built in a no-code tool and is hitting its limits | Rebuild in code from scratch, but with a planned data migration and a period of running both in parallel |
| The product is slow | Measure first, because the cause is usually specific queries or missing indexes, not the choice of language |
| The technology is no longer supported, or nobody wants to work on it | Replace modules gradually, starting with the ones that change most often |
One case deserves a warning: rewriting the product before the hypothesis has been tested. If the MVP has not yet answered its question, rewriting the code is building a second MVP with no new knowledge. You rewrite code when you know what it should do, not in order to find out.
When you do replace part of the system, keep the URLs and interfaces that users and other systems rely on, and move the data as a dry run first, on a copy. Replacement then becomes a series of small, reversible steps rather than a single day on which everything has to work.
Code, rights and documentation: so the MVP can be developed with anyone
An MVP that proves itself will be developed for years, sometimes by a different team from the one that built it. So however modest the first version, a few things should belong to you from the start:
- The code in a repository you have access to. With the full change history, not as an archive handed over at acceptance.
- The economic copyright to the code. Transferred to you in writing, with the fields of exploitation (pola eksploatacji, the specific uses the transfer covers under Polish copyright law) listed.
- Service accounts in your name. Domain, server, payment provider and email sending service.
- Documentation. How to run the project from scratch and deploy a change, and alongside that the hypothesis, the "not now" list and the reasons for key technical choices.
Missing any of these does not get in the way on launch day, but it gets very much in the way when you want to change contractor, bring in an investor or sell the product. We finish every project by handing over full rights to the code and documentation, so that further development does not depend on who wrote the first version.
Frequently asked questions about MVPs
How much does an MVP cost?
As much as it costs to build one path for one group of users, plus a budget for changes after launch. The amount is driven mostly by the number of user roles, payments, integrations with other systems and whether the product has to be an app store app or a browser is enough. You will get a reliable quote once you send the hypothesis, a description of the path and the "not now" list. The product name and a list of ideas are not enough, because every contractor will then quote a different scope.
How long does it take to build an MVP?
It is better to turn the question around: set the date by which you want to know the answer, and fit the scope to it. If the first version does not fit, that usually means the scope is not minimal.
Can an MVP look average and have bugs?
It can look modest, but it cannot fail on the main path. If users drop out because the payment form does not work on a phone, the result tells you about a bug, not about the hypothesis.
Does an MVP need terms of service and a privacy policy?
If you provide a service by electronic means, terms of service are mandatory and must be made available before the contract is concluded. If you collect personal data, the GDPR information obligation applies to you, and cookies other than essential ones require consent. The documents can be short, but they must match what the product really does.
What if the MVP does not work out?
Establish which assumption failed: the problem, the solution, the price or the reach. That determines whether you change the group, the path, the price, or close the project. When changing direction, a good part of the code and data from the first version can often be reused.
Where to start
Before you ask anyone for a quote, write on a single page the hypothesis with its threshold and date, the user group, the path step by step and the "not now" list with reasons. That page will be useful with every contractor, because it lets you compare offers on the same scope.
If you would like us to look at such a description, send it through the contact form. We have been building software since 2020, and we describe what working with us looks like from the first conversation to launch on the process page. You will find the scope of our services for web platforms in our Web Platforms offer.
