Choose the experience around what people need to do.
Explain and convert
A business website helps people understand your offer, find evidence and make an enquiry. Content structure, search visibility and clear next steps matter.
A public website usually helps people understand an offer, find information and take a next step. A web application lets people perform sustained tasks with records, permissions and changing state. A portal commonly gives a particular group a controlled view into those tasks and records.
These categories can overlap. A service company might need a public site and a customer area for documents or project updates. The useful question is not which label sounds more advanced, but what people need to do and whether they need an account to do it.
Describe a representative task from arrival to completion. Include the information entered, the decision made and the result shown. That description helps establish whether a straightforward website feature is sufficient or whether a separately scoped application is needed.
Let people get work done
A portal or application supports tasks: accounts, permissions, bookings, approvals, records or a connected workflow. Start with the users and their main tasks.
List the roles before listing screens. A customer, a staff member and an administrator may view the same record but have different permissions. Specify who can create, edit, approve, export or delete information, and what another user should see after each action.
Design the states around the task: nothing has been entered yet, a record is waiting for approval, a request failed, or an action has already been completed. Clear status and recovery matter as much as the successful screen. Include help and confirmation where a mistake would be costly.
Bring device and working-environment constraints into discovery. Explain whether users work mainly at a desk, on phones, in a warehouse or with intermittent connectivity. Do not assume that a responsive browser interface and a dedicated native application have identical requirements or costs.
Connect the two deliberately
A website can introduce the service while an application delivers it. Define shared data, authentication, support and release boundaries rather than forcing everything into one undifferentiated build.
Choose a first release that completes a coherent task for a clearly defined group. A smaller finished workflow is easier to evaluate than many disconnected screens. Agree the records, roles and integrations needed for that release, then identify what can be introduced later.
Prepare non-sensitive examples of the data and the business rules. Explain where the information currently lives, who owns it and what needs to be retained during migration. Arrange any confidential access separately rather than placing passwords or customer records in an initial enquiry.
The delivery plan should include validation, handover and operation. Decide who checks the release, manages access and responds when an integration fails. The public Applications experience and the service guides can explain the possibilities; the project brief turns your actual requirements into a scoped conversation.