How to scope a web application before development

A brief that asks for a dashboard, an app and an AI assistant describes possible interfaces, not the job the product must do. Before discussing screens, write one sentence naming the user, the task and the useful outcome. For example: a team coordinator needs to assign a follow-up and know whether the person responsible has completed it. This is an illustrative workflow, not a claim about a particular client.

Map the current journey from trigger to completion. Identify who supplies information, who approves changes and where work currently gets stuck. Record what happens when information is missing or someone cannot complete a step. A successful first release should support a complete useful task, even if it supports fewer tasks overall.

Names such as admin and member are not enough to define access. List the records each role can view, create, change, export or remove. Decide whether access belongs to an organisation, a team or an individual record. These decisions influence both the interface and the implementation.

Cashflow illustrates this distinction: its published case study describes business workspaces, separate cashbooks and permission-scoped entry operations. Hiding a button is not the same as enforcing permission where a record is written. Use the example to ask better questions about your own product, not to assume the same model fits every business.

• Which records need a named owner?
• Who can approve or reverse an action?
• What should happen when access is withdrawn?
• What information is sensitive, and what can safely appear in a demonstration?

Separate the complete first workflow from supporting conveniences and future ideas. A manual handover or an export may be appropriate initially, but only if the people operating the product understand the limitation. Deferred work should be written down rather than quietly implied by a polished prototype.

Identify integrations early. A payment service, calendar or third-party data source may require account access, subscription costs and provider approval. Include failure behaviour: what the user sees if an integration is unavailable, whether a retry is safe and who investigates the problem. A proposal should distinguish a feasible integration from an assumption still awaiting validation.

An acceptance criterion describes behaviour that can be checked. Instead of 'the dashboard must be intuitive', state that an authorised user can find their assigned records, inspect the relevant details and complete the agreed action, while an unauthorised user cannot change them. Specify useful empty, loading and failure states alongside the successful path.

For each milestone, name the reviewer, the material they will receive and the feedback window to agree in the proposal. Include the supported devices, test data, content responsibilities and launch dependencies. This creates a shared reference for reviewing progress without promising a timeline before the scope is understood.

You do not need a complete technical specification to begin. Bring an anonymised example of the current workflow, the people involved, the required outcome and the constraints. Identify the decision-maker and explain any target date or budget boundary. Do not send passwords or private customer records in an initial enquiry.

At DelighTech, discovery is the place to test these assumptions and decide what should be scoped next. The deliverables, price, milestones, ownership and support arrangements belong in the agreed proposal. A useful brief helps that discussion; it does not replace it.

• User and task: who needs to do what?
• First release: what must work from start to finish?
• Boundaries: what is deliberately excluded?
• Dependencies: which accounts, content or integrations are needed?
• Review: how will the team recognise that the agreed workflow works?