Decide what the MVP must prove

Write the user, problem, proposed outcome, and riskiest assumption in plain language. If the team cannot say what evidence would change its decision, more features will not make the MVP more informative.

Choose one end-to-end journey that tests the assumption. Include the necessary account, data, confirmation, error, and recovery states so the result can be used outside a presentation.

Break the budget into real work

An MVP estimate may include discovery, user research, UX, visual design, architecture, frontend and backend work, integrations, test automation, manual QA, security, deployment, analytics, and project coordination. Which roles are needed depends on the product and delivery model.

List client-provided work separately, such as content, data cleanup, compliance review, or access to existing systems. Missing responsibilities can create schedule and cost changes even when the feature scope appears unchanged.

Find the scope choices that change cost

Platforms, user roles, permissions, data migration, payment flows, external integrations, reporting, offline behavior, and compliance needs can materially change effort. Test uncertain or expensive dependencies with a small prototype or technical spike before committing to a full build.

A phased MVP can focus on one platform, one user segment, and one primary workflow when that still tests the business assumption. Avoid removing basic security, data protection, accessibility, or recovery needs just to make a budget smaller.

Separate a prototype from production readiness

A clickable prototype is useful for testing language, navigation, and user understanding. It generally does not prove that production authentication, data handling, integrations, uptime, backups, or support will work.

Choose the validation method that matches the question. A prototype may answer whether users understand a flow; a production MVP may be necessary to test real usage, payment, operational load, or repeat behavior.

Ask for a staged estimate

Request separate estimates for discovery, validation, the first production journey, launch readiness, and post-launch learning. Ask for assumptions, acceptance criteria, excluded features, third-party charges, ownership, and ongoing support.

Agree in advance which metrics or user signals will lead to continuing, changing, or stopping. That keeps the MVP focused on reducing uncertainty rather than growing into a smaller version of the final roadmap.