A common reason small app projects struggle is that the first version tries to do everything. A good first version does one job for one group of people, and does it well enough to learn from. Scoping means deciding, in writing, what that is and what it is not.
What "MVP" means in ordinary language
MVP stands for minimum viable product. In plain words, it is the smallest version that is genuinely useful to a real user. It is not a rough or careless version. It is a deliberately small one, which still needs to be reliable. The point is to put something in people's hands, see what they actually do, and decide what to add next from evidence rather than guesses.
Six steps to a scope
- Choose one group of users. "Everyone" is not a group. Pick the people whose problem is most painful, such as your two office staff.
- Choose one job. Describe it as a sentence: "Staff can record a job and see its status." If you need the word "and" many times, you have several jobs.
- List the essential steps. The path from start to finish in the normal case, in order.
- List the exceptions. What happens when a customer cancels, a field is missing, two people edit the same record, or someone leaves?
- Write acceptance criteria. These are plain statements that tell you the job is done, such as "A new job can be recorded in under a minute without help."
- Write the "not now" list. Features you want but will leave for later. Writing them down makes it easier to say no.
Signs your scope is too big
- It has more than one group of users with different needs.
- You cannot describe it in two sentences.
- The list of "must haves" keeps growing.
- It depends on connecting to many other systems.
- You are planning how it will work for thousands of users before you have ten.
A completed one-page scope
FIRST VERSION SCOPE (fictional example) Users: the two counter staff. Not customers yet. The job: record which equipment is out, with whom, and when it is due back. Essential steps 1. Staff search for an item. 2. Staff record who has it and the return date. 3. Staff mark it returned. 4. Staff see a list of items overdue today. Exceptions to handle - An item is already marked out when someone tries to hire it. - A customer returns an item early or late. - An item is damaged and must be taken out of use. - Two staff edit the same item at once. Done means - A hire can be recorded in under a minute without help. - No item can be shown as available and out at the same time. - The overdue list is correct at the start of each day. - Staff can find the history of any item. Not now - Customer logins or online booking - Payments and invoices - Reports and graphs - A mobile app How we will know it worked After four weeks, staff stop using the paper book.
A blank version to copy
FIRST VERSION SCOPE Users: The job (one sentence): Essential steps 1. 2. 3. Exceptions to handle - - Done means - - Not now - - How we will know it worked:
Test the scope before anyone builds
- Fill in the template, then show it to the people who will use it.
- Walk the essential steps with a pen and paper, pretending to be a user.
- Check whether an existing tool already covers the steps. See app, website or existing tool?
- Cut the scope by a third, then check whether it is still useful.
- Find the part you are least sure will work, such as a connection to another system, and test that first.
Why experienced eyes help most at this stage
An experienced person is most valuable here, before anything is built. They notice exceptions you have not listed, ask about data and permissions, and can often see a smaller first version than you had in mind. Ask for help when your scope involves customer information, payments, or other systems. If you used AI tools to produce a prototype, check it against the readiness checklist before real data goes in. Your scope also becomes the heart of a project brief, and it makes comparing quotes far easier.