Web development discovery checklist before scope and quote

Ask the people doing the work to demonstrate a recent, representative journey. Follow the enquiry, order or client request through each handoff. Record the information they need, where it lives and what they do when something is missing. The most useful detail often appears in the spreadsheet or email step that was not mentioned in the original feature list.

Separate observations from explanations. 'Staff enter the same order in two systems' is an observable problem; 'we need a new CRM' is a proposed solution that still needs evaluation. Identify the cost or consequence of the current friction without inventing a precise saving. This gives the project a clear reason to exist and helps avoid automating a process that first needs a simpler agreement between the people involved.

Describe the different users and what each needs to complete. A customer, an approver, an editor and a support person may interact with the same record for different reasons. Write the normal sequence, then add the exceptions that change its meaning: cancellation, missing information, a failed payment or a request to revise an approved item.

Identify who can make each decision. If one team believes an order is final after payment and another changes it during fulfilment, the application needs an agreed rule. Discovery is the right place to surface that disagreement. Keep the map understandable enough that the business can review it without interpreting a technical diagram. A short workflow with clear ownership is more valuable than a large drawing nobody uses to make decisions.

List the material the build depends on: service copy, product records, images, account information, documents and existing URLs. Check whether it is usable, accurate and available to the project. Assign an owner to missing items. A schedule that assumes content will appear later without a responsible person is carrying a dependency that deserves to be visible.

For integrations, confirm access to current documentation and a suitable test setup. Identify the required operations and who controls the external account. Mark unknowns explicitly instead of silently turning them into included scope. If an existing dataset needs cleaning or mapping, treat that as work with an acceptance method. Moving a file is not the same as making its records correct and usable in a new application.

Describe the smallest complete service you can put in front of a user. Include the staff actions needed to support it, not only the public screens. Decide which tasks can remain manual temporarily and which must be automated because mistakes would be costly or confusing. Keep later ideas in a separate backlog with a reason for revisiting them.

Turn key requirements into plain acceptance scenarios. Explain the starting state, the action and the expected result. Include at least one meaningful failure or exception for the most important workflow. These scenarios help design, development and review stay aligned. They also make a proposed scope easier to price because the developer can see what the business expects to inspect rather than guess what a feature label implies.

Create a concise record of agreed requirements, important assumptions, unresolved questions and exclusions. Give each unresolved item an owner and explain whether it prevents estimation or can be handled within a limited allowance. If a technical proof is needed, specify what it will establish and when the result will be reviewed. Discovery should reduce uncertainty rather than become an indefinite project stage.

Use the output to shape a proposal, prototype or focused investigation. Agree how later changes will be evaluated and who consolidates feedback. The depth of discovery should suit the project: a small website may need a short structured conversation, while a connected business application needs more operational detail. Both deserve clarity about what is being built, why it matters and how completion will be recognised.