How to scope a custom business application

A request for an application often starts with a list of screens. Screens alone do not show who makes a decision, what data they need or what happens after approval. To define an initial scope, start with a real task the team already performs.

Describe a user’s end-to-end workflow

Take a common case from start to finish: a request arrives, one person checks it, another handles it, then the outcome is shared. Who is involved at each stage? What information do they consult? Where does work stall today? A few real examples reveal rules that mockups alone may miss.

Then identify less common cases that change the workflow: a corrected entry, cancellation, missing document or hand-off to another team. They do not all need to be built in the first release, but understanding them prevents a data model that is too narrow.

Define data sources and access rights

Record which data users will enter and which will come from an ERP, file or API. Define the source of truth for each field. If data changes elsewhere, decide when the application receives the update and what happens if values conflict.

Define permissions by action: who can view, create, edit, approve or export? Teams have different needs, and some fields may need tighter restrictions. This affects the application design from the start.

Choose a usable first scope

A first release should cover a complete workflow: information comes in, someone processes it and the outcome can be found later. This lets users try real work in the tool. Features outside that workflow can be assessed after initial use.

To validate the scope, write a few observable scenarios. For example: “a coordinator creates a request, a manager approves it, and both can see its status.” These scenarios also help test the application before launch.

Plan deployment during scoping

Where will the application run? Who can deploy and back it up, and who can inspect errors? How will accounts be created? These choices affect cost and schedule. Plan documentation for routine tasks and a handover to the team that will operate the tool.

Useful scoping ends with a defined outcome, sample data, clear roles and a way to verify that the application does its job.