What should the first version of your business web app include?

Start with an outcome, such as assigning a request to an owner and tracking it to completion. Then identify the information, decisions and interfaces required to make that outcome possible.

Consider a hypothetical internal request system. The initial flow might let an employee raise a request, a coordinator assign an owner, the owner record the outcome and the requester see whether it is complete. Each step needs enough information for the next person to continue.

Describe who the first release helps, what work it supports and what completion means in the team's own language. A brief that simply promises to combine everything leaves different people imagining different scopes.

Choose an initial group with real work that can be supported during the trial. A small scope can limit request types or participating teams. It should not leave the selected workflow incomplete and unusable.

For the request example, creating, assigning, tracking and reviewing an outcome may form the core. Numerous report formats or personal appearance settings may not be necessary to establish whether that workflow works.

Some work can remain manual initially, such as a coordinator classifying requests instead of automatic categorisation. Identify who performs it, which information they use and when growing volume will prompt a review. Do not conceal the responsibility as unspecified work outside the system.

Access boundaries, dependable saving and handling failures that affect users should not be removed simply to reduce the feature count. Determine the necessary controls from the information and responsibilities the system actually carries.

Keep deferred ideas with a reason and a condition for reconsideration. An additional report might become relevant when a manager needs it for a recurring decision. Recording an idea does not automatically make it a delivery commitment.

If the application depends on information from an existing program and access is uncertain, investigate that dependency before completing every screen. If users must enter substantial information, use a prototype to establish whether the task fits their normal working conditions.

GOV.UK's alpha-phase guidance uses prototypes to explore ideas and risky assumptions without necessarily building the entire journey. This is a useful distinction between learning before investing and delivering an operational service.

A prototype and a release used for real work are different levels of readiness. A screen with simulated results does not prove that connections, permissions or data storage function. Identify what remains simulated and what has been demonstrated.

Record what evidence would change the decision. If a required source cannot supply dependable information, the right response may be a different workflow or a narrower scope, not simply more interface development around an unresolved dependency.

Instead of requesting notifications, specify when the correct recipient should see an assigned request and who can detect a delivery failure. Instead of requesting search, prepare the records people must locate and the information they know when looking for them.

Include ordinary work and exceptions, such as repeated submissions, insufficient permission and cancellation midway through a task. Describe the required outcome without unnecessarily prescribing every visual detail, leaving room for a usable design.

Agree the initial data and how it will be checked. Opening day should not be the first time the team discovers that existing names, identifiers or work records are unprepared.

Before the trial, assign help, feedback collection and an alternative process if the system is unavailable. Explain what the trial covers and where existing methods remain necessary.

Record completed work, points requiring correction and assistance provided outside the application. Counting accounts or page visits alone does not establish that anyone has completed the chosen workflow.

Afterwards, prioritise recurring obstacles and expansion of proven work before adding every requested feature. A first release succeeds when it establishes a usable foundation and exposes the next decisions clearly, not when the original list becomes longer.

Use the web-app brief and acceptance guide and the comparison of buying software versus building custom to evaluate alternatives against the same scope.