What is an MVP and how to scope one

MVP stands for minimum viable product. It is the smallest version of a piece of software that real people can use to get real value, and that teaches you whether you're building the right thing.

The idea comes from startups, but it works just as well for business software: a customer portal, an internal tool to replace a tangle of spreadsheets, or a booking system. The hard part is not understanding the idea. It is deciding what to leave out.

What an MVP is, and what it isn't

An MVP is a working product, used by real users, for a real task. It is deliberately narrow, but it is not a rough draft. Whatever it does, it should do reliably.

• It is not a clickable prototype or design mock-up, which are useful for testing ideas but don't do real work
• It is not a cheap, rushed version of the full system
• It is not version one of a feature list that will be built regardless of what users say
• It is a focused tool that solves one important problem well and gives you evidence for what to build next

Start with the problem and the core job

Good scoping starts with a single sentence: who has what problem, and what does success look like for them? For example, "Our office staff spend hours each week re-typing job requests from email into our scheduling spreadsheet." The core job of the MVP is then clear: get job requests into the schedule without re-typing.

Next, list the assumptions that must be true for the project to be worth it. Will field staff actually use a phone app? Will customers submit requests through a portal rather than by email? Your MVP should test the riskiest of those assumptions as early as possible.

Talk to the people who will use the software before you write a feature list. Watch how they do the job today, where they get stuck and what they work around. Those observations are usually more reliable than a wish list collected in a meeting.

Deciding what's in and what's out

Write down every feature anyone has asked for. Then sort each one into a group. A common approach is to label features must-have, should-have, could-have and won't-have-yet.

• Must-have: without it, the core job can't be done at all
• Should-have: valuable, but users can work around its absence for a while
• Could-have: nice touches that can wait until you see real usage
• Won't-have-yet: good ideas that belong on a later roadmap

Be strict with the must-have list. A useful test is to ask, "If this were missing, would we delay launch?" If the honest answer is no, it is not a must-have. Manual workarounds are often fine at first. An admin can export a report by hand for a few months while you learn which reports people actually need.

What you shouldn't cut

Minimum refers to features, not quality. Some things belong in every MVP, especially business software that handles customer or company data.

• Security basics: proper logins, permissions and protection of personal information
• Reliable data storage and backups
• A usable interface on the devices your users actually have
• A way to collect feedback and see how the product is being used
• Code and architecture that can be extended rather than thrown away

If your software collects personal information, privacy law applies from the first day. In Alberta, for instance, the Personal Information Protection Act sets rules for how businesses handle customer and employee information. Confirm your obligations with the official source or a lawyer.

Common scoping mistakes

The most common mistake is building for every user type at once. Pick the group whose problem is most painful and serve them first. Another is copying every feature from an existing tool you're replacing, including ones nobody uses. A third is skipping the conversation about what happens after launch, which leaves no time or budget to act on what you learn.

Finally, agree before launch on how you'll judge the MVP. Pick a few simple signals, such as how many staff use it each week, how long the core task now takes, or how many requests arrive through the new channel. Clear measures turn opinions about the product into decisions about what to build next.

Our recommendation

Define the core job in one sentence, sort features ruthlessly, and protect quality on whatever you do build. Then plan time and budget for a second phase shaped by real usage. An MVP is only valuable if you are prepared to listen to what it tells you.

Written by Vishal Singh

Founder of Byte Harbor and a senior frontend and web platform engineer. He builds websites, custom software and AI automation for businesses across Canada and the US.

About Byte Harbor