Commissioning an MVP: agree the scope, prove delivery, keep control

Before you commission an MVP, agree one first-release outcome, the things that stay out, and how you will check what gets delivered. Settle who owns the code, data and accounts before work starts, then accept each numbered release against those written criteria.

A feature list in a proposal tells you little about whether you will get a product you can accept and keep building on. This guide walks through the four documents that decide it: a short brief, acceptance criteria, a rule for sorting requests, and an access list. We work through all four on one example: room booking for a coworking space.

What to send before you ask for a quote

One page is enough. Every team that gets it quotes the same product, and you compare proposals instead of guesses.

1. Who will use it. One group of users to start with: "coworking members", not "anyone who books rooms".
2. The problem. What costs them time today, or goes wrong.
3. One outcome for the first release. What a user should be able to do from start to finish without help from the team.
4. What this release will not include. This list protects your budget more than the feature list does.
5. Constraints. Date, budget or budget cap, required integrations, the data you already have.
6. Who decides on your side. One person who accepts releases and settles scope questions.

If point 3 needs several sentences joined by "and", you usually have two products. Pick the one that has to reach people first.

Example: booking meeting rooms in a coworking space

We prepared this example for the guide. It is an illustration, not a client project.

First release: a member chooses a free slot, books a room and can cancel their own booking. A coordinator sees bookings for their location. In the example each organization has one location.

Scope in five sentences:

• R1. A signed-in member sees free slots and books a room in their organization. The booking is still there after a page refresh.
• R2. Only one booking can exist for the same room and slot, even when two people book at the same moment.
• R3. Members can cancel only their own bookings, and canceling frees the slot.
• R4. A coordinator sees their organization's bookings. Someone from another organization cannot see or change them, including through a direct link.
• R5. Before launch, a named person on your side confirms access to code, hosting, data and billing, and the agreed way to recover data.

Out of scope: payments and subscriptions, native mobile apps, recurring bookings, email and SMS notifications, calendar sync, waitlists, and self-service creation of organizations or rooms. The delivery team sets up the initial accounts and rooms.

Look at R2 and R4. Both seem obvious, and neither shows up in screen designs. If nobody writes them down, nobody checks them.

From a feature list to acceptance criteria

An acceptance criterion describes a situation, an action and a result anyone can see. "Booking works" is not one. "Two people book the same room at the same moment and only one gets a confirmation" is. Good examples describe what the product should do, not clicks in the interface. That keeps them short and easy to follow, and they don't need rewriting when the screens change (Cucumber, "Writing better Gherkin").

Five scope sentences need eight checks:

1. A1 (R1). A member books a room, refreshes, signs out and back in. They see one booking of their own, and the slot is no longer offered.
2. A2 (R2). Two people submit a booking for the same room and slot at the same moment. One gets a confirmation, the other is told the slot is taken. One booking exists. A screenshot does not prove this; you need a record of both attempts and of the stored data.
3. A3 (R3). A member cancels, and a second person books the freed slot. One booking remains, the second person's.
4. A4 (R3). A member tries to cancel someone else's booking without using the screen, for example by changing the booking number in the link. It is refused and the booking does not change.
5. A5 (R4). Someone from another organization tries to open the booking list and a specific booking, then to cancel it. They get no data and the change is refused.
6. A6 (R4). The coordinator opens the list. They see their organization's bookings and none from other organizations.
7. A7 (R1, R4). Without signing in, nobody can read or create a booking.
8. A8 (R5). The person named in R5 signs in with their own account to the repository and hosting, checks data export and billing access, then watches a data restore in a separate environment. Passwords, keys and recovery codes never go into a report.

For each check, write down what you expect and what evidence you want to see. A team that cannot tell you at quote stage how it will show A2 or A5 is probably not planning to build them.

Weekly releases: feedback on a specific release

Ask for a working, numbered release every week, together with the checks it should already pass. In the example that might be A1 and A7 first, and all eight before acceptance.

For those reviews to be useful, every comment should name the release, by number or date, and the criterion it concerns. "In the 14 November release A3 fails: after canceling, the slot still shows as taken" can be fixed and checked again. "Bookings sort of don't work" starts a conversation that never closes.

Keep one acceptance table: requirement, check, release, who checked and when, what was expected, what happened, evidence, decision, recheck.

Defect or change request? Four disputed requests

Most MVP disputes begin with "but that's obvious". A written scope lets you settle them calmly:

1. Two bookings exist for the same room and slot. A defect: R2 and A2 rule it out. The team fixes it and A2 is run again before that requirement is accepted. Your contract decides who pays for the fix.
2. You want a waitlist when a slot is taken. A scope change: waitlists are explicitly out. Name the new outcome and ask the team to estimate what it does to scope, budget and date. Then decide: swap it for something else, add a stage, or defer it.
3. You want weekly recurring bookings. Also a scope change. This release stays as it is until you agree the new scope separately.
4. The booking screen is slow, but nobody wrote down how fast it should be. Neither a defect nor a scope change, but a gap in what was agreed. Look at what is happening and agree a measurable threshold, for example a response time with a stated number of users. Don't treat it by default as extra paid work, or as something you simply have to live with.

Plan for the fourth case before you start: if something matters to you and cannot be checked, add a criterion.

Whose accounts is the product built on?

Handover does not start in the last week. Before work begins, agree whose accounts the product is built on:

• code: a repository in your organization, with you or someone you name as owner, not as an invited collaborator. In GitHub an organization owner has full administrative access, while a member has only what they are granted (GitHub, roles in an organization);
• hosting and database: a cloud account you pay for, or one that can be transferred to you;
• domain, email delivery service, analytics and third-party integrations: each with a named owner;
• billing: who pays for the services and who receives the invoices;
• data recovery: where the backups are and who can restore them.

Everyone gets their own account with the right role. No shared passwords. Moving a repository alone has its own prerequisites and does not move hosting, data or payments (GitHub, transferring a repository). That is why A8 checks access by signing in with the account of the person you named, not the supplier's.

Accepting the release and deciding the next stage

You accept a specific, numbered release against the agreed requirements: each criterion has a result and evidence. If a check failed and you still want to launch, record that as your decision, with the date and the release number.

After acceptance, go back to the out-of-scope list. Users of the first release will ask for some of it themselves; some will turn out not to matter. Only then do you know what belongs in the next stage.

How we do it

At Awakast the first release is our Idea to first version stage: together we shape the problem and the scope, design the key screens with our design partners, build the product and launch it with its first users. It typically takes six to eight weeks. Scope and price, either fixed or a capped budget, are agreed before work starts. Code, data and accounts are yours from day one.

Is there any reason not to work out what your first version should do? Tell us what you're building.