Write the scope before anyone prices it

1. 01

   The problem, in one sentence

   Who has the problem, what it is, and what they do about it today.

   Guidance — If you can't write it in one sentence, the scope will drift. Leave the solution out of this sentence.
2. 02

   Who uses it

   Each type of user, in one line: who they are and what they come to do.

   Guidance — Include the people who run the product (you, an admin, support). They're the users everyone forgets.
3. 03

   The three key flows

   The three journeys that make your product worth using, written step by step as the user experiences them.

   Guidance — Write "The user opens…, sees…, taps…, receives…", not "the system shall…". If you have more than three, you have more than one MVP.
4. 04

   V1: in, out, later

   Three lists.

   • In V1 — what must exist for the three flows to work.
   • Out — what you're deliberately not building.
   • Later — good ideas, parked for after launch.

   Guidance — This is where budgets are saved. Every line you move from "in" to "later" is money you keep for what users actually ask for. A good studio will push back here; be wary of one that doesn't.
5. 05

   The one success metric

   The single number that will tell you V1 worked.

   Guidance — "30 bookings a week by month two" beats "users love it". One number, with a date.
6. 06

   Screens

   The list of screens, with a sketch, a screenshot or a link for each if you have one.

   Guidance — Paper sketches are fine. So is a prototype you built with an AI tool: a clickable prototype is the best scope there is.
7. 07

   Data

   What the product stores, and whether any of it is sensitive (health, payments, children, personal documents).

   Guidance — Sensitive data changes hosting, security and compliance work. Say it now, not in week six.
8. 08

   Integrations

   Everything the product has to talk to: payments, login, email, calendars, third-party APIs, existing tools.

   Guidance — Each integration is real work. Name the service if you know it.
9. 09

   Platforms

   Web, iOS, Android. Which devices, which languages.

   Guidance — "Web first, mobile later" is a legitimate V1 decision — and a cheaper one.
10. 10

    Constraints

    Deadline (and why), budget range, where the data must be hosted, regulations that apply.

    Guidance — A deadline with a reason ("demo to investors on 12 March") is more useful than a date alone. Sharing a budget range isn't a weakness: it lets people tell you what fits.
11. 11

    Admin and back office

    Who manages what behind the scenes: users, content, payments, support requests.

    Guidance — The part nobody scopes, and the part that surprises everybody on the invoice.
12. 12

    What already exists

    Designs, a prototype, an AI-built app, a spreadsheet you run the business on, existing data.

    Guidance — Nothing is wasted: existing work tells a studio what you mean faster than any document.
13. 13

    Open questions

    What you don't know yet, and the assumptions you're making.

    Guidance — Listing what you don't know is a strength. The studio's answers to this section tell you a lot about them.

This is the first step of our scoping Sprint, written down. If you'd rather do it with us, the Sprint also turns it into a clickable prototype and a firm price. Product Discovery Sprint

Made by NexusInsight. A price should come from a scope, not the other way round.