Updated: May 2026.
The founder reads through three proposals. Each promises an “MVP in 8 weeks.” The first one offers a WordPress template with custom fields for 8,000. The second proposes an “MVP” for 200,000 with a 6-month timeline, because “that’s how it’s done with large-scale implementations.” The third one offers something in between, but doesn’t specify exactly what’s included.
Three proposals, the Same deadline, three different products. Each of these compaNos genuinely believes it’s building an MVP. And that’s the problem.
There is no single answer to the question "What is an MVP?" in the industry
Every software company uses this term to mean something different, tailored to whatever they’re currently selling. That’s why, after reading these three proposals, the founder is left on their own. Frustration builds because every budget they had in mind is either “too small for something serious” or “too big for a first project.” He tries to compare the proposals one-to-one, but no two proposals have the Same product definition.
Because "MVP" has become a catch-all term. Software development companys use it as a label for everything from a mockup to the first stage of a large enterprise implementation. The founder signs a contract for "MVP in 8 weeks" and half a year later he is surprised that he got something different than he thought. The Standish Group in its CHAOS 2020 report shows that 70 percent of IT projects exceed budget or schedule. Most of the time it's not because of bad code. Due to the definition crossover at the start.
This article closes this junction. We define MVP from scratch (what IS and what IS NOT), we show why 8 weeks is the only realistic deadline (budget burn × learning cycle × scope discipline), and we give the decision rule: what INCLUDES in the MVP and what WE LEAVE for the second stage. Plus, week by week, as we at JSON Crew deliver in 8 weeks, using a real example.
The central point in one sentence: a real MVP is the smallest version of the product that has users and gives feedback in 8 weeks. Everything else is a different Categories that they sell to you under the Same slogan.
Too Long; Didn't Read · 30 SECONDS
- MVP is not a mockup, POC, short experiment or the first stage of a large implementation. This is a product with real users in 8 weeks.
- 8 weeks is not a marketing slogan. This is the physical limit of budget burn × learning cycle × scope discipline.
- Decision rule: 1 user path from start to finish. Anything beyond that is stage two.
- “From chaos to flow in 8 weeks”: fixed scope, fixed price, fixed deadline.
|
Do you already know that you need an MVP in 8 weeks? A 30-minute diagnostic call. We’ll determine what to include and what to cut for the next phase of your project. |
Schedule a call |
What Is an MVP? A Definition from Scratch
Date Minimum Viable Product (in Polish: minimum viable product) was introduced by Eric Ries in his book The Lean Startup (2011). The original definition reads: “a version of a new product that allows a team to gather the maximum amount of validated knowledge about customers with minimal effort.” Key term: knowledge. Not a product, not revenue, but knowledge.
It sounds simple, but in practice it doesn't work. Because every provider interprets the term differently.
The MVP is NOT a mockup
Model (in English) prototype) is a clickable Figma design or a quick HTML prototype built in three days. It shows how something would look like. It doesn’t show how it performs under load, it lacks server infrastructure, and it doesn’t collect real-world data. A mockup is a tool for designers. It’s not for founders looking to validate a product’s market fit.
MVP is NOT a POC
A POC (Proof of Concept) is a technical validation: can a large language model successfully parse a PDF, can an IoT bridge operate within a 200-millisecond latency, or will 3D in a browser cripple performance? A POC has one goal: to eliminate technical risk. There are no users. There is no feedback loop. It provides the engineer with confidence, not the founder with validation.
MVP is NOT a short-term experiment
A short experiment (in English) spike) is a 1–2 week study, usually conducted as part of a larger project. The goal: to quickly determine whether Framework X can handle a specific use case, in order to make an architectural decision. The experiment is not shared with the client. There is no release. It is a team tool.
An MVP is NOT the first stage of a large-scale implementation
The most common abuse. A software development company yeses on a 200,000-unit project, breaks it down into “phases,” calls the first one an MVP, and delivers it after 4–6 months. This is a large-scale corporate implementation spread out over time, not an MVP. The client pays for 60 percent of the target functionality but is billed for 100 percent of the time spent. There is no validation because the scope was contractually defined at the outset.
Not a mockup, not a POC, not a quick experiment, not the first phase. Just a product that has users and provides feedback within 8 weeks.
Operational definition
MVP =. a product that has real users and provides validated feedback within 8 weeks of launch. Three keywords: users (not a demo), feedback (not declarations), 8 weeks (not “stages”).
The four categories above (prototype, POC, experiment, first phase) make sense, but you’re buying a different product than you think when someone sells them to you under the name MVP. The first question to ask about any offer: Will I have users in 8 weeks who are actually using the platform and providing feedback? If the answer is, "Well, in the first phase, we're showing a demo to the board," then that's not an MVP.
Why exactly 8 weeks? A solid rationale
Where did that number come from? Why not 6? Why not 12?
Eight weeks isn’t just a round number chosen for marketing purposes. It’s the point where three physical constraints intersect: budget burn, the learning curve, and scope discipline. Any shorter, and one of those three will break down. Any longer, and one of them will break down too. One by one.
Budget overspending vs. the learning cycle
A typical MVP in Poland in 2026 costs 30,000–90,00PLN 0 (more at Q3: How much does a custom MVP app cost?). The founder covers this amount out of their own pocket or from the first investor (preseed, business angel). Each additional week burns through 4,000–12,00PLN 0 of the budget. As a result, after 8 weeks, the founder starts checking the balance instead of the results. Unfortunately, after 12 weeks, the balance usually yeses precedence.
Second layer: the Build-Measure-Learn cycle (Eric Ries). A typical cycle lasts 3–4 weeks. Build a feature, measure whether customers are using it, and learn what to improve. Eight weeks cover two cycles. That’s the minimum needed to make one meaningful turnaround before the buffer is depleted. If you cut it short (4 weeks), you’re skipping a cycle, which means your MVPon’t have a chance to adjust. If you extend it (16 weeks), you’re wasting money on cycles without gaining any new insights.
Creator Mode vs. Manager Mode
Paul Graham in his essay Maker’s Schedule, Manager’s Schedule (2009, literally: “Creator Mode vs. Manager Mode”) describes the dynamics of an engineering team. Programmers need long uninterrupted blocks (4–6 hours) of deep work. Every interruption yeses 30–60 minutes to regain focus. Projects without a release date lose the team’s rhythm after just 8–10 weeks.
What happens then: the team starts polishing instead of delivering. Code refaCTOring begins even before the first user. Next comes rewriting the abstraction layer. Long discussions about the “perfect architecture” follow. As a result, the lack of release pressure kills discipline. After 12 weeks without a single user, the team loses its bearings and delivers not what the client needs, but what the programmer considers elegant.
Scope discipline as an enforcement mechanism
Every founder starts out with 12 to 30 features in mind. That’s only natural. The first conversation: “That’s the bare minimum; anything less doesn’t make sense.”. Each of these 12 points is important to the founder, because each one addresses a specific pain point that he or she has identified.
The problem: In 8 weeks, you physically build 1 user path, not 12. In practice, therefore, you have to make a choice. Eight weeks is a timeframe that forces you to make that choice. If you go shorter (4 weeks), you cut out the main spricerio and end up with a mockup. If you go longer (16 weeks), however, you include the second phase in the scope, which means you’re back to dealing with the challenge of a large-scale implementation spread out over time.
If you cut it short, you end up with a prototype. If you stretch it out, you end up with a scope creep. Eight weeks is the only timeframe in which an MVP is truly an MVP.
What is included in the MVP, and what is not
The decision rule in a nutshell: 1 user journey from start to finish. Login → main action → result. Everything else is part of the second stage.
In practice, it looks like this:
| He is named MVP | DOES NOT enter (second stage) |
| 1 main user action (the most important spricerio) | Spricerio 2, even a "short" one |
| Display the result: desktop, PDF, email, or notification | Settings panel, profile management |
| Basic logsn (1–2 roles) | Advanced roles and permissions (RBAC), multi-tenancy, workspace switching |
| 1–3 integrations critical to the spricerio | Integrations "just because the customer wants them" |
| Custom graphic design for the main screens only | Modular system, reusable components |
| Responsive website (or native mobile app, if that is the primary use case) | A native mobile app when it's not the primary use case |
| Hosting + Basic Monitoring | Multiple regions, advanced monitoring, integration with operational chat |
| Polish interface language | Multilingual, white-label |
| Manually onboarding the first users | Automated input, in-app tutorials |
| AI functions only when they are the main spricerio (e.g. data extraction) | AI features "because it's fashionable" |
Three rules that hold this list together:
First rule: one main spricerio. If the app has 2 user types (e.g. admin and customer), in MVP you only go with one. The second one you show by substitution (manual export, manual configuration by developers). Then you go back to the second one in the next step after validating the first one.
Second rule: the result must be visible. If the spricerio ends with "data stored in database", there is no loopback. The user must see the effect: PDF, e-mail, notification, change in the interface. Without a visual result, MVP does not generate validated knowledge.
Third rule: integration only when it blocks the spricerio. Stripe only comes in when the main spricerio is payment. Likewise, transactional email only when the primary spricerio is notification. However, Customer Relationship Management, analytics, ERP and BI are all second stage, no exceptions. Even when the client insists.
Sound drastic? That’s the point. Because without this three-principle discipline, the scope will balloon back to 12 features, the project will drag on for 16 weeks, and your wallet will be empty.
Anti-pattern: The founder crams the second phase into the MVP
The most common spricerio from our experience in 2026: A client comes in with 12 features. "That's the bare minimum; anything less doesn't make sense. A customer without X won't pay."
The scope audit we conduct during the first two days shows that 11 of these 12 items belong to the second phase. Only one feature is actually a core feature. Despite this, the client usually doesn’t believe us. So we narrow it down to one, and we record the rest in the second-phase log (a separate document, signed, and clearly documented). Then development yeses 4 weeks. Demo on Friday of week 6: the client sees a working spricerio with 1 feature and says: "Actually, I don't need X right now. Let's leave that for later."
This isn't a story we made up for the article. It keeps happening in every other the MVP project we're delivering.
4 Signs That a Client Is Trying to Squeeze a Second Phase Into the MVP
- “The MVP must have at least five user flows, otherwise no one will buy it.”
- "Without integration with [system X, Y, Z], it won't work"
- “Advanced roles for five types of users are absolutely essential from day one”
- “AI and personalization are our key differentiators; they must be included in the MVP.”
Each of these arguments may make sense for ready product. However, none of them make sense for validation MVP. Because an MVP doesn't sell. An MVP comes first teaches: Is this particular spricerio useful? Does anyone use it? Would anyone pay for it?
I know how this sounds from a founder’s perspective. It sounds like a software company that doesn’t want to deliver. Or like someone who deliberately does less than they promised. That’s exactly how it looked to us when we first cut 11 out of 12 features for a client. The client was furious on Friday, but thanked us on Monday after the demo. We repeated this cycle about 30 times before we trusted the process.
Counterargument: Anyone who pushes for a second phase in the MVP doesn't have an MVP. They have a large-scale implementation that hasn't been completed. And almost always, this kind of approach ends up exceeding the budget, the deadline, or both. The second phase creeps in through the back door every week if it isn’t outlined separately from the start.
How JSON Crew Delivers in 8 Weeks: Week by Week
Since scope discipline is crucial, the question is: how do you enforce it in practice when a client says on Friday, “Just quickly add X”?
We’ll show you exactly what the 8-week delivery cycle looks like. This process is the Same for the product configurator, the customer portal, and the dedicated MVP (e.g., the IoT dashboard).
WEEKS 1–2 · DIAGNOSIS
What we validate, not what we build
2–3 sessions with the founder, 1 user journey, 1 deliverable, a list of cuts for the second phase approved. Deliverable: a one-page brief.
WEEKS 3–6 · CONSTRUCTION
Daily presentation, weekly edition
Four weeks of coding per feature. A release to the test environment every Friday. No polishing before the first user.
WEEKS 7–8 · FINALIZATION AND LAUNCH
Soft start + feedback loop
Bug fixes, production environment, first 5–20 users from the customer base. Feedback in week 8 = decision on the second phase.
Weeks 1–2. Assessment (NOT development)
Goal for the first two weeks: to define what we validate, not what we build. The difference is fundamental.
What we do: 2-3 sessions with the founder, mapping the user journey (1 persona, 1 spricerio), choosing the main action, deciding what to CUT to the second stage (signed list). Week 1-2 result: 1 page brief, which says exactly 1 script + exactly 1 result + a list of 5-15 cuts for the second stage.
This is the moment when 80 percent of projects are saved or derailed. If you don't define your second stage cuts in the first 2 weeks, range creep creeps in through the back door every week.
Week 3-6. Construction (daily showcase, weekly edition)
Four weeks of clean coding for 1 spricerio. Every Friday release on a test environment for the founder. Daily presentation within the team (15 min, "what works, what blocks"). No "polishing" before the first user, refaCTOring postponed until the second stage.
Two things help us here. Firstly, 1-page brief from weeks 1-2, to which we return every week and say "this is not in the brief, it goes to the second stage". In addition fixed price contract. In practice, the client does not pay for our overtime when he comes up with ideas, because our scope is limited by contract.
Weeks 7–8. Final touches and a soft launch
Bug fixes, production environment setup, first group of users (typically 5–20 people, the first users from the client’s database). Soft launch in week 7, feedback loop in week 8.
In Week 8, the founder has three things in hand: a working product, early adopters, and a list of second-phase cuts for discussion. This is the moment to decide on the next step based on actual feedback, not on predictions.
A real-life example: KG Electronics (IoT Smart Control panel, case study). The scope for weeks 1–2 was narrowed down from 14 features to 1 main use case (real-time monitoring + alerts). Development in weeks 3–6, soft launch in week 7 with 8 users from the client’s database, full launch 12 weeks after the start (including 4 weeks for the second phase following feedback from week 8). We apply the Same principles to configurators (PVC Windows, anonymous agricultural project) and client dashboards.
“From Chaos to Flow.” Why This Term Is Also a Hit in Western Markets
Most software development compaNos in Western markets use a time-and-materials (Time and Materials) billing model. The client pays for the team’s hours, the scope is “flexible,” and the schedule is “iterative.” It sounds reasonable, but in practice, it means an open-ended bill with no end in sight.
Our promise is different. 8 weeks. Fixed coverage. Fixed price. The client pays for results, not for hours. The scope is defined in terms of functionality (as specified in the contract), and the deadline is fixed (as specified in the contract). The second phase involves a separate contract, a separate budget, and a separate decision following feedback from week 8.
8 weeks. Fixed coverage. Fixed price.
This term is our niche, which is why we also use it as our positioning in English-language sales conversations. In Polish, we always say: “From a flood of offers to a smooth process in 8 weeks.” In English, the Same message reads: “Most engineering compaNoss bill by the hour and by materials. We deliver a finished product in 8 weeks.”
When the MVP is ready for the second phase
Three signs that the MVP has validated the hypothesis and it’s time for the next phase. Each of them is concrete and measurable; none requires “market intuition.”
First sign: users provide feedback without being asked. In week 8, you sent out 5 surveys asking for feedback. Then, in weeks 9–12, users started saying things like, “Hey, I’m missing X,” “It would be nice to have Y,” and “What about Z?” Organic engagement means that retention has evolved into an active relationship with the product.
Second indicator: retention rate above 30 percent in the fourth week. Of the 20 users in the soft launch, 6 or more return in week 4 on their own initiative (without your reminder email). That’s the minimum threshold for making a sensible investment in the second phase. However, with retention below 30 percent, the next phase is merely optimizing a product that no one is using.
The strongest indication: someone tried to pay. Even though the MVP doesn't have a payment screen yet, someone asks "How do I buy this?", “How can we implement this here?”, “Do you have an offer for a larger organization?”In practice, willingness to pay is a form of validation that no market research can replace.
Without these three signals, the second stage is a divergence in scope, not scale. Without them, it’s better to stop after 8 weeks, accept the negative feedback, and shift to a different main spricerio in a new MVP.
What now?
If you're planning your first MVP for 2026, you have three reasonable options:
- Describe the scope in one sentence: “An MVP that performs [1 key action] for [1 persona] and delivers [1 outcome].” If it can’t be described this way, the scope is too broad.
- Save the cuts from the second stage separately, with the date: Anything that didn't fit into the sentence above goes on a separate list. You'll come back to it after Week 8 with concrete feedback.
- Choose a supplier with a fixed price and a fixed delivery date, not on an hourly basis. Because without a feature that enforces an 8-week limit, 8 weeks will stretch to 16, and 16 to 24.
OPTION 1 · CONVERSATION
30-minute diagnostic consultation
We’ll determine what stays and what goes for the next phase of your idea. No strings attached, no PowerPoint presentations.
OPTION 2 · PRICE LIST
How much does a dedicated MVP app cost?
Actual price range in Poland in 2026, modular design, price comparison between Poland, Germany, the UK, and the US.
Frequently Asked Questions
Is 8 weeks enough time for anything serious?
Yes, for an MVP in the strict sense of the term (Eric Ries). Eight weeks is enough for one user journey from start to finish with real users and a feedback loop. If you need more (advanced roles, multi-tenant support, a native mobile app, 5+ integrations), that’s not an MVP—it’s the first phase of a major deployment, and you should call it what it is in the brief.
How can you tell the difference between an MVP and a prototype in a software development company's offerings?
Four questions about the proposal. First: Will I have real users by week 8 (not just a demo for the board)? Next: Is the result visible to the user (PDF, desktop, email)? Third question—does the contract have a fixed scope and a fixed price? Finally: Is the list of cuts for the second phase signed off on in the brief? Four “yes” answers mean an MVP. However, even a single “no” means a different product under that label.
How much does an 8-week MVP cost?
In Poland in 2026, the typical price range is 30,000–90,00PLN 0, with 44,00PLN 0 being the sweet spot. For a lower price (15,000–30,00PLN 0), you get the Lite plan (a template plus basic logsc). For a higher price (60,000–90,00PLN 0), you get the Pro plan with enterprise-grade integrations. Full price range plus a comparison with DE/UK/US: P3 How much does a web application cost in 2026?.
What if a customer wants more than one user flow in the MVP?
We cut the scope by 80–90 percent for the second phase and present a one-page brief in the second week. On Friday, the client says, “But without X, it won’t work,” and on Monday, they see a working prototype with one feature and say, “Actually, I don’t need X right now.” This happens in every other project. The proof-of-concept works.
How do you calculate ROI for an MVP?
MVP does not have revenue-based ROI metrics in the traditional sense. It has learning metrics: the number of validated hypotheses, retention at week 4, and willingness to pay (whether anyone attempted to make a purchase). The second stage is valued based on these metrics, not before them. Full ROI breakdown from the configurator (example of the K1 cluster): E9 ROI from the configurator.
About the author
Jędrzej Siewierski – President and Co-Founder JSON CrewFor the past 8 years, he has been building custom applications, product configurators, and customer dashboards for B2B manufacturing compaNos in Poland and the European Union. He specializes in 8-week MVPs (fixed price, fixed scope) and the digital transformation of B2B sales. He has delivered projects for KG Electronics (IoT Smart Control dashboard), as well as clients in the renewable energy, agricultural, and window industries. He teaches his team that “whoever pushes for a second phase in an MVP doesn’t have an MVP.”
Related articles:
- How to Choose a Software Development Company After a Bad Experience – 7 Questions (E5)
- How much does a dedicated MVP 2026 app cost? (P3)
- What is a Product Configurator? A Complete Guide (E1)
- How to Choose a Company to Build an IoT Dashboard (E11)
External sources:
- Eric Ries, The Lean Startup (2011): The origin of the term MVP
- The The Standish Group, CHAOS Report 2020: 70 percent of IT projects go over budget and miss their deadlines
- Paul Graham, Maker’s Schedule, Manager’s Schedule (2009)
