Start MVP development with the question you need to answer
An MVP is valuable because of the assumption it can test with real users, not because it contains a large number of screens. Product discovery identifies the target user, problem, and current way of solving it. “Anyone can use this” is not enough to scope a first release. A narrower group and a specific job under defined conditions create a clearer starting point.
For an illustrative B2B booking product, the first question might be whether businesses consistently accept online requests. A full loyalty system or numerous visual themes may be unnecessary to answer it. The learning objective, expected behaviour, and observation criteria are recorded together. When demand is unclear, interviews or a manual pilot may be useful before custom development. An MVP engagement does not guarantee commercial success, fundraising, or product-market fit.
Limit version one around a complete user journey
When working with a software partner, select an end-to-end journey rather than a disconnected feature list. A user submits a request, a business accepts it, and the user receives status information. That sequence describes a useful scope more clearly than a collection of screens. Administrative actions needed to operate it are included; an operator needing a developer for every exception can make the first release impractical.
Work is divided into essential, deferrable, and excluded items. The question for each request is whether the learning objective can be answered without it. Core access, security, and data-integrity needs are not removed simply because the release is small. At the same time, building infrastructure for an unproven large-scale audience can consume the starting budget. The decision record explains why something was deferred and what evidence would justify reconsidering it.
User journey
One complete scenario reaching an initial value moment. The required screens follow from the journey, rather than defining the goal.
Operational journey
Invalid requests, cancellations, support, and administration. Explicitly planned manual steps may be appropriate at the start.
Deferred work
Later features and conditions for reconsideration. Excluding a feature from version one does not mean the idea lacks value.
FROM READING TO A NEXT STEP
What should your first release help you learn?
Share the idea, intended user and first complete job. We can define scope, dependencies and the learning plan together.
Distinguish a prototype from a working MVP
Testing the journey through a UI/UX design process can expose misunderstandings before implementation. A clickable prototype shows screens and navigation; it does not prove that payments, stored data, or integrations work. A presentation demo, research prototype, and MVP for real users are separately defined deliverables.
Design review includes empty lists, incomplete information, and errors as well as the successful flow. In a booking example, what happens when capacity is full is a product decision. Discovering that answer accidentally during development can create scope and usability problems. If an AI-built prototype already exists, reusable parts are assessed, but a convincing demonstration is not automatically production-ready. Data sources, access conditions, and maintenance ownership still require review.
Manage implementation and release through visible small deliveries
The web application development scope follows the user’s need. A competitor having a mobile app is not by itself a reason to launch in two app stores. Device capabilities, notifications, or the usage context may justify mobile delivery; otherwise a web approach can be considered. Technical choices should account for implementation and maintenance capacity rather than a preferred technology name.
Completed journeys are demonstrated against agreed acceptance conditions. New ideas are assessed for priority and impact instead of being silently added to the current work. Release preparation covers access roles, backups, basic monitoring, error handling, and a support path. Checks follow the actual scope rather than an identical enterprise checklist for every MVP. Ownership of accounts and source-code handover are explicit in the agreement. Delivery is more than sending the founder a working link.
Discovery and decisions
Write the learning objective, core journey, exclusions, and technical dependencies before committing to a broad build.
Visible implementation
Demonstrate working journeys and assess the schedule and budget effects of requested changes.
Release and handover
Deliver review results, account ownership, maintenance responsibility, and a support route together.
Include post-development costs in the MVP budget
A founder may need technical leadership support after the first release as well as before it. The budget includes more than screen design and coding. Hosting, external services, support, data operations, and further development capacity all matter. If AI is included, usage costs and handling unsuccessful outputs deserve their own discussion. Features do not all carry the same maintenance burden.
Estimates record assumptions. If roles, integrations, platforms, and acceptance conditions are unknown, a single precise price can mislead. The proposal explains which resources belong to the client and who pays for licences. After launch, behaviour data and user feedback inform the next investment. If the intended learning has not occurred, the team can reconsider the problem before adding features. The aim is not to squeeze a large product promise into a small budget, but to deliver a working first release that enables a better next decision.
One-time work
Discovery, journey design, development, and acceptance checks. Scope changes trigger a review of the estimate.
Recurring costs
Hosting, external subscriptions, support, and maintenance. Explain which costs change with usage.
The next decision
Review activation, operational effort, and user feedback. Further investment follows the learning objective rather than the longest feature list.
BEFORE YOU DECIDE
Frequently asked questions
Is an MVP the same as a prototype?
No. A prototype can demonstrate screens and a journey, while an MVP performs the defined job with real users. A presentation demo and a live product are different deliveries. Acceptance conditions should state which integrations and operations actually work.
How many features should version one contain?
There is no fixed number. The learning objective and complete user journey determine the essential scope. Other ideas are deferred with reasons. More features do not automatically produce better validation, especially if they distract from the question being tested.
Should we build web or mobile first?
Consider usage context, device requirements, and budget. Being in an app store is not an objective by itself. Web delivery may be worth examining if device capabilities are unnecessary. Platform decisions also create maintenance and publishing responsibilities.
Will an MVP help us secure investment?
A working product can make a discussion more concrete, but investment depends on many commercial and financial factors. Development does not guarantee funding. The intended learning and the limits of the evidence should be clear when presenting the product.
Who owns the source code and accounts?
Ownership, access, licences, and third-party components should be defined in the agreement. Identify the accounts the founder controls and the handover documents required. Receiving a live link alone is not the same as a complete technical handover.
What should happen after the MVP launches?
Review feedback, activation, and operational effort. If the intended learning has not occurred, reconsider the problem or audience before automatically adding features. The next release decision combines evidence with the team’s ability to deliver and maintain it.
LET’S DEFINE THE SCOPE
What should your first release help you learn?
Share the idea, intended user and first complete job. We can define scope, dependencies and the learning plan together.
Discuss MVP scope