How to Scope a Custom Web Application
A useful web-application scope describes users, workflows, data, permissions, rules, integrations, exceptions, quality, and operating ownership.
A useful web-application scope describes users, workflows, data, permissions, rules, integrations, exceptions, quality, and operating ownership.
This guide is written for business decision-makers. It provides practical planning information, not legal, financial, security, medical, or other regulated professional advice.
1. Describe outcomes before screens
Start with who uses the application, what triggers their work, which decision or result they need, and what indicates completion. Walk through one representative case from beginning to end. Screen lists can hide missing business logic, while workflow descriptions reveal records, roles, state changes, approvals, notifications, and dependencies.
2. Model data, permissions, and exceptions
Identify authoritative records, fields, relationships, validation, retention, and migration. Define which roles can create, view, change, approve, export, or delete each type of information. Add empty, missing, duplicate, delayed, rejected, unauthorized, and recovery cases. Integrations should include authentication, limits, monitoring, and manual fallback—not only the happy path.
3. Set a release boundary and acceptance criteria
Choose one complete vertical slice for the first release and separate later capabilities. Define performance, accessibility, security, availability, browser, environment, testing, documentation, training, deployment, support, and ownership expectations. Acceptance criteria should describe observable behavior and data results so review does not depend on personal interpretation at the end.
Decision checklist
- Users, roles, trigger, workflow, decision, completion, and owner
- Records, relationships, permissions, validation, states, and exceptions
- Integrations, migration, notifications, reports, files, and recovery
- Quality attributes, acceptance, deployment, documentation, support, and ownership
A practical decision rule
Scope one end-to-end workflow deeply enough to expose data and exception requirements before adding a broad inventory of secondary features.
Use the rule in context
Document the current evidence, remaining uncertainty, responsible reviewers, and the smallest next step that can be validated. A written project scope should make assumptions, exclusions, dependencies, acceptance criteria, ownership, and ongoing operating obligations visible.
Frequently asked questions
Should the scope include technical architecture?
It should include enough architecture and constraints to support estimates and risk decisions without pretending every implementation detail is final.
Can requirements change during development?
Yes, but change should be evaluated against the agreed outcome, budget, dependencies, acceptance criteria, and release boundary.