How to Scope a Web App Before Anyone Writes Code

Teams lose months when the scope is a list of screens. Screens change. The jobs do not: a buyer places an order, an admin corrects a record, a manager sees what is late. Write those jobs down before you argue about the navigation.

Start with one complete path

Pick the path a real user must finish without help. For a marketplace that might be list, enquire, and confirm. For an internal tool it might be create a record, assign it, and close it. Everything else is a later release until that path is boringly reliable.

• Who uses it, and what they are trying to finish
• What data is required, and what can wait
• Which step fails today, and how people work around it

Write the edges while they are still cheap

Empty states, permissions, and exports are where web apps get expensive. If finance needs a CSV every Monday, that is scope, not a nice-to-have discovered in week eight. A short written scope that names roles, records, and the first release is enough to estimate. A fifty-page specification usually is not.