A public website explains what a business does and helps a visitor choose a next step. A web application helps people carry out work: submitting, reviewing, updating or finding records. The right choice depends on the job, who uses it and how information moves. A local fictional office workflow demonstration shows a narrow review queue, not a complete application.
Both can belong to one business. Check existing products before choosing a custom build.
Describe what people need to do
Write down what a person needs to do from beginning to end. If the task is to understand a service, check practical details and call or message the business, a public website may be enough. If people need to enter information, have someone review it, change its status and return to it later, the work may call for a managed product or an application.
A website can have interactive parts, and a web application can have public information pages. The distinction is about the main job and its operating rules, rather than whether a page has a button or looks like a dashboard.
Compare the options by the work they support
Consider this fictional example: a small repair service wants to explain its work and help people make contact. Separately, its staff want to record incoming requests, assign an owner and review progress. The public introduction and the staff workflow are different needs; they do not automatically require one new system.
| Option | Typical job | Users, records and review | Care after setup |
|---|---|---|---|
| Public website | Explain services, coverage, practical details and contact choices. | Visitors read public content. A call or message can begin a conversation without creating an internal record automatically. | Someone keeps contact details, service information and any time-sensitive content current. |
| Content system or online store | Let an assigned editor update pages or products, or manage a catalogue and defined store tasks. | Editors may have different access from visitors. Store records and order steps depend on the chosen product and configuration. | Plan account ownership, product or content updates, subscriptions where applicable, and support for the selected system. |
| Configured no-code product | Adapt an existing product for a request list, simple tracking or another bounded workflow. | Check whether its roles, fields, permissions, review steps and exports fit the real process. | Assign an administrator and understand product changes, access, data export and ongoing subscription or support needs. |
| Internal web application | Support a defined staff task when existing products do not fit it well. | Specify who can create, view, edit, approve or export each record, and what happens when information is missing or rejected. | Plan hosting, backups, access changes, fixes, monitoring, documentation and who handles support. |
| Customer portal or dashboard | Give customers or managers a controlled view of relevant records or status. | Decide which person sees which data, how it is supplied, how often it changes and who checks the displayed meaning. | Maintain account access and data connections; review what users see when information is delayed or unavailable. |
These are planning categories, not a product comparison. A configured product may handle the workflow well; a custom application is only one possibility when the actual requirements cannot be met sensibly another way.
Check what you already use
Before adding software, list the tools and records already involved. A shared inbox, spreadsheet or product account may cover the need if staff can find the latest information, know who acts next and correct mistakes. Also note where a duplicate entry or unclear handoff causes trouble.
- Can the current product represent the required fields and status changes?
- Can the right people access it, while others are kept out?
- Can an owner review, correct and export the information?
- Who administers the tool and deals with changes or access problems?
If these answers are workable, improving the existing process may be enough. If not, describe the specific gap before comparing configuration or development options.
Map users, records and review points
For an operational tool, trace one ordinary case. In the fictional repair-service example, a staff member might record a request, another person might assign it, and an owner might review a proposed next step. That outline still leaves questions: what fields are needed, who can change them, how are duplicates handled, and what should happen when information is incomplete?
Include exceptions and responsibility. Identify who is allowed to approve a record, what the requester can see, and who corrects an error. Decide whether the records contain sensitive information before choosing where they should be stored. Do not collect extra details simply because a form can ask for them.
Choose one useful first release
Keep the initial scope to one complete task. For example, it could be recording and assigning an incoming request, with an agreed review step. Leave reports, automated reminders or customer accounts out until there is a clear need and a person responsible for each part.
Define how you will recognise a usable result: the intended users can complete the task, required fields are checked, the right person can review it, and an error has a known path to resolution. This is a scope discussion, not evidence that any system has been implemented or tested.
Plan ownership and maintenance
Ask who controls the domain, hosting, product accounts and application data. Agree who can change content or user access, who checks updates, what can be exported, and who handles backups and support. A handover should explain the system and its boundaries, not only provide a login.
A public information site may need occasional content updates. A store, configured product or application has additional operating responsibilities that depend on what it does and the services it uses. Clarify these responsibilities before committing to a design or build.
Prepare the project questions
Before discussing a proposal, write down:
- The user and task that matter most.
- What people need to read, enter, decide, approve or retrieve.
- Which existing tools and records are involved.
- What should happen when information is incomplete, rejected or delayed.
- Who will own access, review changes and maintain the result.
For a public site, compare the business website service. For a defined internal workflow, see web applications. If existing tools need to exchange information, consider software integration. The static website or CMS guide covers a related publishing choice. To discuss a project, use the contact page.