A customer reading about your services and sending an inquiry presents a different requirement from someone signing in, uploading a document, approving a quotation and tracking delivery. Both screens may look simple. The second needs rules, data and responsibilities that page count cannot reveal.
Before requesting a “company website” or “web application”, describe each user's task and what must remain saved after the browser closes. A label helps describe the project but cannot replace its scope. A project can combine public company information with a private customer or employee workspace.
The distinction starts behind the page
A company website usually presents information, services, content and contact routes that staff can update. A web application adds browser-based work: creating and reviewing records, changing status and accessing data according to a role. These examples clarify scope rather than impose rigid technical boundaries.
MDN explains that websites can generate dynamic content and process browser requests and data. It is therefore inaccurate to assume every company website is static or that a database alone makes a complex business product. Ask who uses a function, what changes as a result and who approves that change.
A fictional translation company
The company wants language and service pages, articles and inquiries. A public website with content management may meet that initial need. It later requests file uploads, customer quotation approval and delivery tracking, while staff assign work. This creates a workflow requiring its own definition.
It does not necessarily require rebuilding everything. The company may already have a suitable request system needing a customer interface, or may begin with inquiries only. Make the decision visible: which step occurs on the website, which remains in another system or manual process, and who explains status to the customer.
A matrix for defining the request
| Question | What it reveals | Scope record |
|---|---|---|
| Do users see different information? | Accounts, roles and access boundaries. | Who can view or change the request or file. |
| Does a user resume previous work? | Saved state across sessions. | What persists and how the latest status is shown. |
| Is review or approval involved? | State transitions and responsibilities. | Approvers and rejection or amendment behavior. |
| Does data come from another system? | Integration and an external source dependency. | Data owner, direction and unavailable-service behavior. |
| Will staff operate it daily? | Operational tools, permissions and training. | Staff tasks, records and handover outputs. |
Do not count answers to produce an automatic verdict. An existing service behind a simple website may suffice, while one sensitive function may need deeper investigation. The matrix exposes proposal questions; it does not assign every project a fixed score or assumed price.
Separate public pages from the workflow
Describe public pages, content, languages, editing and forms in one part of the proposal. For each workflow, identify its user, inputs, states and outputs. In the translation example, uploading is more than an attachment field when a file belongs to a private request and later appears only to authorized people.
Define staff requirements too: a request list, assignment owner, status approvals and an explanatory change record. If these are excluded, identify the system or process covering them. “Admin panel” should not obscure the difference between editing page copy and managing customer requests.
Write states a design image cannot show
What happens when upload fails, a session expires or a customer edits an approved request? What does someone see when attempting to open another customer's request? Discuss required business behavior and agreed tests without using real customer files in a demonstration.
MDN's client-server explanation helps show that clicking a button initiates processing and a result, rather than only changing a screen. Your quotation request need not describe protocols. It needs a clear outcome for success, failure and returning to a task later.
Select an operable first phase
If the current objective is organized inquiries, you may start with public pages and a form, deferring a portal. If the problem is customers lacking order visibility, public information pages alone do not solve it completely. Choose a journey serving the objective and explain how deferred parts operate.
Check whether hosting, workflow support, integration updates and external licences appear as understandable items. Browser access does not make all operating costs identical. The provider should explain the effects of data, accounts and integrations.
A decision check before sending the request
- Describe public visitor tasks and customer or employee tasks after sign-in, if present.
- Select a core task and identify its starting data and final state.
- Identify existing-system capabilities and what needs building or integration.
- Review one exception and returning after the browser closes.
- Ask the provider to restate the scope in your language before discussing price.
For broader budgeting, see the company website scope and cost guide. For tasks, use the requirements-preparation guide. When you need a working browser workspace, discuss web application development using the matrix and journey rather than only naming a product resembling the idea.
Sources
MDN's server-side introduction and client-server overview were opened on 3 November 2026. The example and matrix are original buyer guidance rather than a mandatory technical classification or market pricing. The text was prepared with AI assistance and review of its content and sources.
