How to scope a custom software project before you ask for a quote

Two vendors quote for "a booking app". One says six weeks, the other six months. Both may be honest — they simply imagined different products. The cure is a scope that describes outcomes, people and rules clearly enough that everyone pictures the same thing.

You do not need technical knowledge to write a useful scope. You need to describe your world precisely. This guide walks through the parts that matter most.

1. Start with the outcome, not the features

Write one or two sentences about what should be different once the software exists. "Parents can pay fees online and the office no longer reconciles bank statements by hand" is far more useful than "we need a payment module". Outcomes let a good team propose simpler ways to reach them.

Add how you will know it worked. Fewer phone calls? Faster month-end? Measurable signals help prioritise later.

2. List the people who will use it

For each group, note what they need to do and anything special about them: field staff with poor connectivity, administrators who live in spreadsheets, customers on low-end phones, people who prefer Hindi. These details drive design and cost more than most feature lists.

3. Describe the workflows step by step

Walk through the main journeys as they happen today and as you want them to happen. Include the awkward parts: approvals, exceptions, refunds, cancellations, what happens on holidays. Edge cases are where estimates go wrong.

1. Who starts the process and how?
2. What information is captured?
3. Who checks or approves it, and with what limits?
4. What notifications go out, to whom, on which channel?
5. What records or reports come out at the end?

4. Name the systems it must connect to

Integrations are a common source of underestimated effort. List every system that should send or receive data — accounting software, payment gateway, CRM, messaging, hardware devices — and whether each has an API you can access. If you do not know, say so; discovery can find out.

5. State your constraints honestly

• Budget range — a range lets a vendor propose the right shape of solution rather than guessing.
• Deadlines that are real — an academic year start or a regulatory date, not an arbitrary target.
• Data and compliance — personal data, children's data, payments or health information change the design.
• Who will run it afterwards — your team, the vendor, or nobody yet.

6. Define a first release

Most successful projects ship a smaller first version than originally imagined, then improve it with real feedback. Mark each requirement as must-have for the first release, next, or later. This single exercise often halves the initial cost and time.

7. Ask for the right things in a quote

With a scope like this, ask every vendor for the same things so quotes are comparable: assumptions, what is excluded, team composition, delivery milestones, how changes are handled, testing approach, hosting and running costs, and who owns code and accounts.

When to pay for discovery instead

If the project is large, involves several organisations or depends on unknowns — a legacy system, an unproven integration — a short paid discovery is cheaper than a fixed quote padded for risk. The output should be a document you could hand to any vendor.

If you would like help preparing a scope, our project brief wizard walks through these questions, and we will reply with clarifying questions rather than an instant number.