A web app is software people use through web technology to perform tasks, such as submitting a request, managing records or working through an account. A website may mainly present information, while a web app usually needs more interaction and state. The boundary overlaps: one site can contain both public information and an application behind sign-in.
An installable Progressive Web App is one possible web-app approach, not another name for every website. Google’s web.dev guide describes progressive enhancement, installation and device integration, while qualifying the broader relationship between web and platform-specific applications. Choose the behaviour your users need before choosing a label. Progressive Web Apps.
How is a web app different from an ordinary website?
Consider a public service page describing appointment options. Its main job may be to answer questions and direct an enquiry. Now consider a customer choosing a slot, saving contact details, checking an existing request and changing it. That second journey needs application behaviour: identifiable records, decisions about access and a clear response when an action cannot be completed.
This is an illustrative comparison, not a claim about a Spout customer project. It shows why “we need a website” can conceal different engineering requirements. A public page and an account system may share branding while needing different acceptance tests.
Avoid treating interactivity alone as the definition of success. An animated menu is interactive but does not solve the record, permission or transaction problems of an application. Begin with the user’s task and the information the system must preserve between steps.
Which delivery approach should you consider?
| Approach | Typical purpose in the brief | Question to resolve |
|---|---|---|
| Information website | Explain services and help people contact the business | Can visitors find and understand the answer? |
| Browser-based application | Complete tasks and manage records | Are actions, access and saved state correct? |
| Installable PWA | Add an app-like launch experience to web software | Which installation and device capabilities work on target devices? |
| Platform-specific app | Meet requirements tied to a device platform | Are the native requirements worth the separate delivery responsibilities? |
The table is an editorial requirements aid, not a universal technology ranking. A project can combine rows. For example, a public information site can link to a browser-based customer portal without making every page installable.
Does a web app need to be installed?
No installation requirement follows merely from calling something a web app. The web.dev guide describes installation as part of the PWA approach, with a home-screen icon and a standalone window among the possible installed experiences.
Do not assume that adding an icon creates a complete application. Authentication, data handling and business rules still need to work. Nor should installation become a barrier for a customer who only needs to complete a short browser task. The appropriate choice depends on the intended journey.
The guide also discusses operating-system integration, such as URL handling. Those capabilities should be checked on the actual browsers and devices used by the audience. A capability described for the platform is not evidence that your implementation supports it everywhere. Web and installed-app behaviour.
What does offline support really require?
The web can support offline content and interactions, but offline behaviour needs deliberate design. A cached public page is different from a queued order or an editable record. Decide what can be read, changed or submitted without a connection and what must wait.
For a hypothetical request form, a useful offline state might preserve the user’s unfinished text and clearly state that it has not been submitted. An unsafe state would show “request received” when no server has accepted it. Define those messages before implementation rather than treating offline support as a checkbox.
When the connection returns, test whether the action is submitted once, duplicated or left pending. Record the server-side result separately from the local screen. This is an original acceptance requirement, not a promise that every PWA automatically handles synchronisation correctly.
MDN explains how a service worker can fetch page resources into a local cache and intercept later requests. Its cache-first example may return an older stored response; a network-first strategy instead tries the server before falling back to cache. Choose deliberately for each kind of information: displaying a cached service description and displaying an old appointment balance carry different consequences. Background work is also bounded: browsers can stop service workers, and a restarted task may begin again rather than resume. Test repetition and freshness instead of promising that an offline badge guarantees delivery. MDN offline and background operation.
An original interaction-state definition card
Use a card for each important application action:
User task: what the person intends to achieve.
Starting state: what record exists and what the user is permitted to see.
Input: information needed, with unnecessary personal data excluded.
Validation: conditions that must be met before submission.
Pending state: what the screen says while the result is unknown.
Accepted state: evidence that the server accepted the action and the reference retained.
Failure state: explanation and recovery route without losing valid work.
Repeat behaviour: what happens when the user clicks again or reloads.
Access boundary: who can later view, change or cancel the resulting record.
Offline boundary: which parts work without a connection and which remain unsent.
The card turns an abstract feature into observable behaviour. It also gives the business a way to review wording and permissions before development decisions become difficult to change.
How should you choose the first version?
Select a complete task rather than a long list of disconnected screens. A customer request workflow might include submission, confirmation, staff visibility and a way to correct an error. A login screen and empty dashboard would not complete that task.
Ask for a demonstration using an ordinary user account and realistic test records. Attempt an invalid input, interrupted connection and repeated submission. Inspect the resulting records instead of judging only the visual presentation.
Separate public information from private application data in the content plan. Pages intended to answer general questions should remain understandable without signing in. Account-specific records need an appropriate access model. This article does not prescribe a universal authentication architecture; it identifies decisions the project must make explicitly.
What should your project brief contain?
List the user groups, complete tasks, records, permissions, integrations and devices that matter. Add the interaction-state cards and the evidence needed to accept each workflow. Keep installation and native-device features tied to an actual user need.
Discuss the requirements through Spout’s web development service or start an enquiry with the task you want people to complete and the records it affects.
Identify the operating owner separately when discussing hosting for the application.
By Spout Team. Prepared with AI-assisted drafting using the linked primary documentation.