On an ordinary website, people mainly read information. In a web application, they work: prepare requests, approve documents, plan shifts or check orders. The interface opens in a browser, but business rules, a database and connections to other systems sit behind it. Specify the product through working activities rather than just a list of desired screens.
When the browser becomes a work tool
A web application is useful when several people need shared, current information and a clear process for changing it. A dispatcher creates a request, an assignee sees the assignment, and a manager tracks progress. If everyone keeps their own spreadsheet copy, the team must separately work out which version is correct. A shared system can provide one record and rules for accessing it.
A browser-based format does not automatically mean the product works offline or identically on every device. Supported browsers, mobile workflows and connection-loss behaviour must be agreed separately. Unreliable networks require additional decisions about local data and synchronisation.
The interface, server and data have different jobs
The interface helps a person perform an action. The server checks permission and business conditions, while the database stores the accepted result. Hiding a button does not prohibit an operation: server-side checks are needed regardless of the screen’s appearance. Similarly, a Saved message should follow confirmed persistence, not appear immediately after a click.
-
Define the data and operations available to each role.
-
Describe record states and the permitted transitions between them.
-
Agree which changes must remain in the history.
Learning example: editing a request concurrently
Two employees open the same request. The first changes the assignee; the second changes the deadline. If the system simply stores the last submitted form, the second action may silently erase the first. The workflow needs a conflict rule: record-version checking, a message about newer changes or another agreed mechanism. This is a data and process issue rather than a button-colour choice.
Retries after network delays require separate testing. Users need to know whether a request is still running or can be retried. For an operation that creates a request, define the intended retry outcome before development so repeated clicks do not produce several identical tasks.
How we plan the first web application version
In ALL IT Agency’s web development work, we distinguish public pages from tools that change operational data. For the first version, choose a complete journey: create a request, assign responsibility, do the work and close it. A collection of attractive but disconnected screens will not let the team test that sequence.
Preparation produces a role model, record structure, integration plan and acceptance scenarios. For external services, clarify authentication, test-environment availability and exchange limits. These affect the estimate just as much as the number of pages.
Test behaviour as well as appearance
During acceptance, follow one process using different roles. Try opening another user’s data, saving an outdated form and retrying after a disconnection. Check that the result remains available after signing in again. The team needs instructions, an access-management procedure and a clear way to report problems.
Sources and further reading
