# MVP development: how to scope a minimum viable product

Published 24 July 2026. Updated 25 August 2026. By the LOLCorp engineering team.

**Short answer:** Scope an MVP around one core user journey that proves your idea. List features, rank them must, should, could and won’t, build only the musts, and launch to real users quickly. An MVP is the smallest release that teaches you whether the product is worth building further.

## What an MVP is, and is not
A minimum viable product is the smallest working version that delivers real value to a real user and lets you learn. It is not a sloppy prototype, and it is not a stripped-down version of everything. It is a complete, if narrow, experience.

## Step 1: define the single core journey
Write one sentence: “A [user] can [do the key thing] so that [outcome].” Everything in the MVP should serve that sentence. If a feature does not help the journey, it waits.

## Step 2: prioritise with MoSCoW
List every feature you can think of, then sort it.
- Must have: the product fails without it
- Should have: important but not vital for launch
- Could have: nice if time allows
- Won’t have (yet): explicitly postponed

## Step 3: cut ruthlessly, but keep the foundations
Cut breadth, not quality. Skip rarely used settings and advanced reporting, but keep authentication, data protection and sensible error handling. Choose an architecture that can grow, so the MVP is a base, not a throwaway. For SaaS, build multi-tenancy early (how to build a SaaS product).

## Step 4: agree timeline and cost
A focused first release often reaches production in about 4–6 weeks. Use our instant quote generator to see how features and users change the range, and read fixed price vs time and materials to choose a commercial model.

## Common traps

- Adding “just one more” feature before launch
- Building for imaginary scale instead of real users
- Skipping onboarding and analytics, so you cannot learn
- Treating the MVP as the final product

## Example: scoping an MVP for a booking platform
A hypothetical example shows how the method works for a service-booking product.
- Must have: customers can search, pick a time and pay; providers can set availability and see bookings
- Should have: email reminders and a simple review system
- Could have: coupons, multi-currency, a mobile app
- Won’t have yet: advanced analytics, marketplace commissions, integrations with third-party calendars

## Next steps
Once you know what the MVP includes, write it down using our requirements brief template and follow the development process. See also our SaaS development service and the complete guide.

## FAQ
### How many features should an MVP have?
As few as it takes to complete the core journey well. Often that is a handful of features, not dozens.

### Can an MVP be built fast without being low quality?
Yes. Narrow scope with solid engineering foundations beats broad scope with shortcuts.

### What comes after the MVP?
Watch real usage, fix friction, then add the next highest-value features from your “should have” list.

---
Canonical page: https://lolcorp.co.uk/guides/mvp-development-scope/
Publisher: LOLCorp PVT LTD (Company No. 15380538), 71-75 Shelton Street, Covent Garden, London WC2H 9JQ, United Kingdom. Phone +44 20 3576 3417, email hello@lolcorp.co.uk.
Last generated: 2026-10-25