How to scope a software project before you hire anyone

1. Define the problem and the outcome

Not "build an app", but the problem behind it: "customers wait two days for a quote, and we want to quote the same day." The outcome is how you will judge whether the project worked, so make it something you could actually check.

2. Name the users

List each type of person who will use the first release — customers, staff, administrators — and what each of them needs to get done. Leave out people who will only matter later.

3. Map the key journeys

For each user, write the steps from starting to getting the outcome: "a customer requests a quote, uploads their details, receives a price, then accepts and pays." These journeys, not a list of features, are what you are really buying. Most first releases need three to five of them.

4. Prioritise: must, should, later

Sort everything into what must be there at launch, what should follow soon after, and what can wait. If everything is a must, the first release will be late. A useful test for each item: would we delay the launch for this?

5. List the constraints and integrations

• The budget range, and the deadline — with the reason it matters.
• The systems it must connect to, and who controls them.
• Data and compliance requirements, such as UK or EU GDPR.
• Who will run and support it after launch.

6. Expose the risks and unknowns

Write down the assumptions you have not tested yet and the technical questions nobody can answer today. Unknowns are normal; hidden ones are what make projects expensive.

What a good brief looks like

• The problem and the outcome.
• The users of the first release.
• Three to five key journeys.
• A must, should and later list.
• Constraints, integrations and the deadline.
• Open questions and risks.

Keep it to one or two pages. Anyone quoting from it should be able to tell you what they would build first, and why.

When to get help

If the scope still feels fuzzy, or quotes come back wildly different, a short product discovery phase turns it into a plan you can take to any team — the output is yours either way. If the first release is a test of the idea, read what an MVP should include next.