Most founders arrive at their first build with a long feature list and a short runway. The list grows with every investor conversation and every competitor demo, and the launch date moves with it. MVP development is the discipline of deciding what goes in the first version, what waits, and what must never be cut regardless of how small the product is.

This guide is written for founders and product leads in the US and UK who are planning a first version of a web or mobile product. It covers what an MVP actually is, how to pick the one problem it solves, a practical way to cut scope, technology choices that do not box you in, the basics you should not skip, and what to do once real users arrive.

Quick answer

A minimum viable product is the smallest version of your product that real users can use to complete one valuable job from start to finish, built so that you learn whether the business idea holds up. Build the single core workflow, the minimum needed to trust it (sign-in, basic security, backups), and the means to measure and change it (analytics and a repeatable release process). Leave out secondary user types, edge cases that a person can handle manually, admin polish, integrations nobody has asked for yet, and anything built for a scale you have not reached.

What an MVP is, and what it is not

Eric Ries, who popularized the term, defined it this way: "the minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort" (Startup Lessons Learned, 2009). In the same post he adds that an MVP "is not about creating minimal products."

Two points follow from that definition. First, the purpose is learning, so an MVP that nobody measures has missed its own point. Second, "viable" matters as much as "minimum." A version that is too broken or too thin for anyone to finish a task teaches you nothing about demand; it only teaches you that broken software is unpopular.

Founders often use prototype, MVP and first release as if they meant the same thing. They answer different questions and carry very different costs.

The practical consequence: do not pay production prices for a prototype question. If you are still unsure whether customers understand the concept, clickable designs and ten conversations are cheaper than any code. Start MVP development once the open question is about real behavior, not first impressions.

Choose the one problem to solve

An MVP should serve one type of user doing one job. If you cannot state that in a sentence, the scope is not ready to estimate. A useful template is:

For [a specific user], who struggles with [a specific problem], our product lets them [complete one outcome] without [the current workaround].

Three checks help you choose between candidate problems:

• Frequency and pain. A problem people hit weekly and already pay to work around (with spreadsheets, an assistant, or a clumsy tool) is a better first target than one they notice once a year.
• A reachable first customer. You should be able to name the first twenty people or companies you will ask to use it. If you cannot reach them, you cannot learn from them.
• A testable assumption. Write down the riskiest belief behind the business, for example "clinic owners will let patients book without a phone call." The MVP exists to prove or disprove that belief.

Two-sided products such as marketplaces need extra care, because both sides have to get value on day one. A common approach is to build software for the side that is harder to win and serve the other side manually at first.

Cut scope with must, should, later

Once the core problem is fixed, every proposed feature goes into one of three buckets. This is a simplified form of MoSCoW prioritization, a method documented by the Agile Business Consortium, which sorts requirements into Must Have, Should Have, Could Have and Won't Have this time.

• Must: without it, the core workflow cannot be completed or the product cannot be trusted.
• Should: important, but there is a workaround, even an awkward manual one.
• Later: wanted, agreed, and explicitly not in this version.

The test the Consortium recommends for a Must is to ask what happens if the requirement is not met. If the honest answer is "we would work around it," it is not a Must. Its guidance also recommends that Must Haves take no more than 60% of the planned effort, which leaves room for the surprises every build contains. If your Must list consumes the whole budget, the plan has no slack and the scope is still too large.

Here is an illustrative example (not a client case study): a booking product for independent physiotherapy clinics, where the assumption being tested is that patients will book online without calling.

Common things to leave out of a first version: a second user type, a self-service admin panel for tasks you can do directly for customers, custom reporting, multiple languages and currencies, integrations with tools your first customers do not use, and automation of steps that happen a few times a week. Doing some things manually behind the scenes is a legitimate MVP technique, as long as customers get the outcome they were promised.

Technology choices that keep options open

The goal of an MVP technology stack is not to predict your needs in three years. It is to avoid decisions that are expensive to reverse. A few principles do most of the work.

• Prefer well-established, widely used tools. A mainstream framework and a standard relational database mean documentation is plentiful and other developers can take over the code. An established framework such as Laravel also covers common needs such as user authentication in a standard, documented way, so your budget goes on what makes the product different.
• Build one application, organized cleanly. Splitting a first version into many separate services adds operational work before you know which parts will need to scale. A single well-structured application can be divided later.
• Buy the commodity parts. Payments, email delivery, SMS and file storage are usually better rented from specialist providers than built. Keep each behind a small wrapper in your own code so that changing provider later is a contained job.
• Decide web versus mobile on evidence. If the core workflow works in a browser, a responsive web app is usually the faster test. If it depends on the camera, location, offline use or push notifications, plan for mobile from the start; our comparison of native, Flutter and React Native covers that choice.
• Own your assets. The source code repository, cloud account, domain, app store accounts and third-party service accounts should be in your company's name, with your developers given access. This matters most if you outsource; see our guide to outsourcing software development from the US or UK.

If you are shipping mobile apps, allow for store rules in your plan. Apple's App Review Guidelines state that demos, betas and trial versions do not belong on the App Store and should go through TestFlight, and that apps supporting account creation must also offer account deletion within the app. Google Play requires personal developer accounts created after November 13, 2023 to run a closed test with at least 12 testers opted in for 14 continuous days before applying for production access (Play Console Help). A mobile MVP therefore needs to be a finished small product, not a rough draft.

What not to skip, even in an MVP

"Minimum" applies to features. It does not apply to the handful of things that are cheap to do at the start and painful to add after an incident.

Security basics

Early users are trusting you with real data. The US Federal Trade Commission's Start with Security guide is a readable checklist for non-specialists; its lessons include not collecting personal information you do not need, restricting access to sensitive data, storing passwords securely and updating third-party software. For the build itself, ask your developers how they address the OWASP Top 10, which OWASP describes as a standard awareness document for web application security risks (the most recent release is the 2025 edition). In practice the minimum is encrypted connections, properly hashed passwords, checks that each user can only see their own records, secrets kept out of the code, and dependencies kept up to date.

Privacy from the first design

Collecting less data is both a security measure and a scope reduction. In the UK, the Information Commissioner's Office says organizations must integrate data protection into processing activities from the design stage and throughout the lifecycle. In the US, obligations vary by state and sector; California's CCPA, for example, applies to for-profit businesses that meet certain thresholds. This is a high-level description, not legal advice. If you handle health, financial or children's data, take advice before you build.

Backups you have tested

Losing customer data in month two can end a startup. Guidance for small businesses from the NI Cyber Security Centre includes identifying what data you need to back up, keeping backups separate from the original, considering the cloud, and making backups routine. For a hosted product that means automated database backups stored apart from the live system. One further step is worth the hour it takes: restore a backup before launch, because a backup that has never been restored is unproven.

Analytics tied to your assumption

Because the MVP exists to produce learning, decide before launch which few events prove or disprove your riskiest assumption: sign-up, first completed core action, return visit, payment. Track those and little else. Add basic error monitoring so you hear about failures from your tools before you hear about them from customers.

A way to change things safely

You will change the product weekly after launch. That requires version control, a staging environment separate from production, a release process that is scripted instead of performed by hand, and the ability to roll back. Without these, every fix carries the risk of breaking something else, and the pace of learning drops.

What drives timeline and budget

Any figure quoted without knowing your scope is a guess, so it is more useful to know what moves the number. When you compare proposals, look at how each one treats these drivers.

Also budget for what follows the build. Hosting, third-party service fees, app store accounts, bug fixes and the first rounds of changes after launch are part of the cost of an MVP, and the changes are where its value is realized.

For technical readers

• Default to a modular monolith on a relational database with managed hosting. Introduce queues, caches and separate services when a measured problem calls for them.
• Use schema migrations from the first commit, and keep configuration and secrets in the environment, not the repository.
• Build the API so that web and mobile clients can share it, even if only one client exists at launch.
• Write automated tests for the core workflow, authentication and anything touching money. Full coverage can wait; those cannot.
• Put new or risky functionality behind feature flags so it can be released to a subset of users and switched off without a deployment.
• Set up centralized logs, error tracking and uptime checks before the first external user.
• Keep a short technical debt list recording each shortcut and the trigger for fixing it.

After launch: what to do with what you learn

Launching to a small, known group is better than a public announcement. Give the first users direct access to you, watch where they get stuck, and fix those points quickly.

Then compare the results with the assumption you wrote down at the start and choose one of three paths:

• Persevere. Users complete the core workflow and return. Move items from Should into the next release, in the order users ask for them.
• Adjust. People sign up but do not finish or do not return. Talk to them before adding features; the cause is often the workflow or the target user, not a missing capability.
• Stop or change direction. The assumption was wrong. That is an acceptable result of an MVP, and a far cheaper one than discovering it after a full build.

As usage grows, revisit the shortcuts on your technical debt list, automate the manual steps that have become frequent, and strengthen the parts that are now business-critical. Resist adding features because a single prospect asked for them.

Frequently asked questions

What is the difference between a prototype and an MVP?

A prototype is a mock-up or throwaway demo used to test whether people understand and want an idea. An MVP is working software used by real customers with real data to test whether they will use it and pay for it. A prototype is discarded; an MVP is usually the foundation of the product.

How many features should an MVP have?

There is no fixed number. An MVP should contain everything needed for one type of user to complete one valuable job from start to finish, plus sign-in, basic security, backups and analytics. If a feature can be removed and the core job still works, it belongs in a later release.

Should a startup MVP be a web app or a mobile app?

Choose the platform where your first users already do the job. A responsive web app is usually faster to build and change, and avoids app store review. Start with mobile when the core workflow depends on device features such as the camera, location, offline access or push notifications.

Can I build an MVP with no-code tools?

Yes, for simple workflows and early experiments. Check first whether you can export your data, whether the platform meets your privacy obligations, and what you would do when you need something it cannot support. Plan for the possibility of a rebuild if the idea succeeds.

Will the MVP have to be rewritten later?

Not necessarily. An MVP built on a mainstream framework, with version control, migrations and tests around the core workflow, can be extended for a long time. Rewrites tend to follow MVPs where those basics were skipped, or where the product changed direction completely.

How long does MVP development take?

It depends on scope, not on a standard figure. The main drivers are the number of user roles and platforms, integrations, payments or regulated data, design ambition, and how quickly decisions are made. A written Must list is the fastest way to get a reliable estimate.

Conclusion

A good MVP is narrow, not careless. It solves one problem for one kind of user, leaves out everything that a person can do by hand for now, and keeps the foundations that protect customer data and let you change course: security basics, tested backups, analytics and a safe release process. Its job is to answer a business question at the lowest sensible cost.

The next step is one you can take without a developer: write your one-sentence problem statement, your riskiest assumption, and a Must, Should, Later list. If you would like a second opinion on that scope or an estimate based on it, you can send it to Entrant Technologies for a quote.