MVP Development Process: Six Steps from Idea to Launch

Many companies start by trying to finish the entire app before launch. The budget drains, the schedule slips and the market opportunity passes while it happens. The MVP development process exists to prevent exactly that: spend the smallest reasonable amount to validate the most important assumption, then decide whether a full build is worth funding. Below is how the steps actually run in practice at Juhui Software, and what a quote for an MVP version normally includes and excludes.

Step one: turn the idea into a testable hypothesis

An MVP development process does not start with a UI. It starts with one sentence: "If we offer this capability in this situation, this specific group of users will respond in this specific way." That sentence needs a defined user, a measurable behaviour and a validation window. Without those three, everything built afterwards has no yardstick to be measured against.

A common failure is to launch a project with unfalsifiable phrasing such as "improve the user experience" or "validate market demand". Replace that with something like "within three weeks, store managers will submit inspection records by phone on their own, at least twice a week." Now every interview and every tracked event has something to line up against.

Step two: pick a single core feature chain

With the hypothesis fixed, the second step is narrowing the scope. List all candidate features, then ask of each one: if this feature did not exist, could the hypothesis still be validated? If yes, it moves to version two or three and out of the MVP.

That filter typically leaves three to five core screens. In an EV charging scenario, an MVP often contains only the device list, charge order lookup and abnormality alert push. For a smart vending cabinet, it may keep scan-to-open, restocking records and per-cabinet revenue view. Pushing goods management and multi-dimensional reporting past validation is the single highest-leverage trade-off in the MVP development process.

Step three: a clickable prototype in two to three weeks

The prototype stage validates whether the flow works and whether users understand it, not whether it looks good. A low-to-mid fidelity clickable prototype in two to three weeks is usually enough to check three things: can a user complete the core task with no instruction, are key pieces of information where users expect them, and are there steps that only make sense after formal training.

Problems found here are extremely cheap to fix. The same problem found after development starts usually means rewriting code. The page list confirmed and signed off at this stage becomes both the development scope and the acceptance basis for later, which makes this confirmation record a real project asset.

Step four: develop in iterations, not one delivery

The defining feature of the build phase is its rhythm. An MVP development process does not require everything at once; it works in one- or two-week sprints, each ending with a demonstrable version the business side can run, rather than a status report to read.

Technically, keep the necessary architecture and database design, and cut features rather than structure. That way version two can add capabilities without rewriting the core data model. This is fundamentally different from simplifying the architecture to save money: the first approach saves features, the second saves future rework, and the second rarely pays off.

Step five: launch to validate, not to launch

The purpose of launching an MVP is to obtain judgement, not to publish. At minimum, prepare three sets of data: feature usage rates showing which paths are actually used and which get bypassed, retention and frequency showing whether users come back, and exception feedback showing where users get stuck or drop off.

Agree the validation window before launch, for example four to six consecutive weeks with no major feature changes, so that data is not distorted by structural edits. If usage comes in far below expectations, the correct move is to return to step one and re-examine the hypothesis, not to immediately add features.

Step six: review and plan version two

The last step is the review decision: continue, adjust or stop. The review should produce a version two feature list and timetable, and separate conclusions that came from data from those that are still judgement. Knowing which is which is the most valuable output of this step.

What an MVP version costs: typical ranges and composition

On cost, the right yardstick matters. For the same feature count, complexity can vary several-fold, so a range is more useful than a single number. At typical domestic market levels, a moderately complex MVP version generally falls between 80,000 and 250,000 RMB. Where hardware integration, complex third-party interfaces or private deployment are involved, it can reach 250,000 to 500,000 RMB. Single-page tools and simple form applications can be covered for far less.

Quotes usually break down into four parts: product and UI design, roughly 15% to 25% of the total and rising with screen count and custom design demands; development and implementation, 55% to 70% and the bulk of the work; testing and launch support, 10% to 15%; and project management and coordination, around 10%. The part most easily squeezed is testing. When the testing line falls clearly below 10%, it usually means testing has no independent budget, and the consequences tend to appear after launch.

One caution: an MVP is not a cheap version. What an MVP reduces is feature scope and visual polish, never stability or data security. Skipping permission checks, payment security or audit logging to save money can destroy the first batch of users' trust and corrupt the very data the validation depends on, which wastes the entire exercise.

Practical recommendations

Three recommendations from years of delivery work are worth repeating. First, put the MVP scope in a contract annex and have both sides sign it. This constrains the vendor and equally protects the client from silent scope creep. Second, define the trigger for version two, for example "start version two once daily active usage reaches a stated level", so the decision rests on objective evidence rather than a temporary judgement call. Third, pick a team with relevant experience; for systems involving device protocols such as charging piles or vending cabinets, whether the team has done hardware integration before directly determines the debugging time inside the MVP phase.

The core of the MVP development process is trading one controlled, small investment for one clear decision. The six steps above look unremarkable, yet each one addresses a specific risk: an unclear hypothesis sends development in the wrong direction, an over-large feature list breaks the budget, a missing prototype causes rework, a lack of iteration lets defects pile up, missing data prevents any decision, and a skipped review turns the investment into a repeat. Execute each step properly and the question of what an MVP version costs stops being a matter of guesswork.