*By: Fluw editorial team · September 2, 2026*
“We need a website” can describe several different jobs. One company needs to explain an offer and collect an enquiry. Another needs customers to find and compare current products. A third needs clients to see documents and request status after signing in. A fourth wants to replace a repeated spreadsheet-and-chat process with one controlled workflow.
All four outcomes live in a browser, but they have different users, data, permissions, and ownership. The best starting point is therefore not a template or a feature list. Ask: who must do what, using which business data?
Fluw helps companies create websites and web services with the materials and data they already maintain. You can describe a task, add files or an available source, open the result in a browser, and refine it. This guide gives you a practical way to choose a first scope without confusing a useful proof with a finished integration.
Four formats at a glance
| Format | Main audience | Core action | Typical data | Owner of the next step |
|---|---|---|---|---|
| Website or landing page | Prospects, partners, candidates | Understand the offer and enquire | Copy, images, contacts, terms | Marketing or sales |
| Catalog or storefront | Visitors, buyers, procurement teams | Find, compare, select, and request a product | Products, prices, stock, specifications | Commercial or e-commerce team |
| Client portal | Authenticated clients or partners | Check a status, document, order, or request | Profiles, requests, orders, documents, statuses | Client service or account manager |
| Internal tool | Employees and managers | Create, review, approve, or assign work | Forms, directories, roles, statuses, history | Process or operations owner |
The formats can be combined. A website can lead to a catalog, a catalog can collect an enquiry, and a portal can show its status. For a first release, however, choose one primary path. Otherwise the team tries to prove value, model data, and design every exception at the same time.
Website: explain the offer and start a conversation
A website or landing page is the right format when visitors are still learning about the company. They need to understand what you offer, who it is for, why it matters, and what to do next. That next action might be an enquiry, a call, a booking, a download, or a handoff to another service.
The data is often relatively stable: positioning, services, case descriptions, images, contacts, legal details, and answers to common questions. The difficult part is usually not a complex permission model, but a clear sequence of pages and a trustworthy form. Marketing owns the content; sales or support owns the incoming request and its follow-up.
Imagine a manufacturer launching a new equipment line. In the first phase, it may not need a complete store. Visitors might need to understand the use case, compare a few models, and request a recommendation. A focused website can test that journey before the company models every warehouse and price rule.
A website is too small when people must repeatedly sign in, see personal terms, choose from a large assortment, or track an ongoing process. It can remain the entry point, while the main scope becomes a catalog or portal.
Catalog: make product data useful for selection
A catalog matters when the visitor’s value comes from finding and comparing specific items rather than only reading about the company. The user may filter products, open specifications, choose an option, and send a request or order.
Catalogs demand data discipline. Each item needs a stable identifier, name, category, specifications, images, and a clear rule for displaying price and availability. The source might be a spreadsheet, file, CRM, or accounting system. Decide where each value comes from, how often it is refreshed, and what the visitor sees when the source is temporarily unavailable.
In the connected catalog example, focus on the chain rather than the decoration: source, field mapping, and final card. If part of the connection is still a demonstration, label it clearly. The catalog data guide covers SKU structure, images, price conditions, and stock states in more detail.
A catalog does not have to take payment. A distributor can publish an assortment and collect a quote request. An equipment company can offer specification-based selection. In both cases, the main action is choosing a suitable option, not necessarily checking out online.
Client portal: serve an existing relationship
A client portal is useful when the user already has a relationship with the company. They may need to see requests, orders, contracts, invoices, documents, messages, or the next step. A partner may need different data and permissions from an end customer.
Here, sign-in is a data boundary, not decoration. Define which records belong to a user, which are visible to an organization, who can change a status, and which actions need an employee’s review. Start with one role’s path: “a client opens a request, adds a document, reads a comment, and understands what to do next.”
Do not begin with a menu containing every possible section. Choose the recurring question that brings people back: “What is the status of my request?” or “Where is the current document?” Add related actions only after that path is clear.
A portal may use CRM or other system data, but a system name is not evidence of a ready connector. You still need access rules, fields, refresh behavior, and an owner for errors. The client portal preparation guide lists the decisions to make before designing screens.
Internal tool: control repeated work
An internal tool is for employees, not the public audience. It makes a repeated process visible and manageable: receive a request, check its data, assign an owner, approve a decision, store history, or generate a document.
Roles and transitions matter more here than visual presentation. Who creates a record? Who checks it? What counts as complete? Can it return for clarification? What happens when an employee changes teams? The answers become statuses, permissions, required fields, and an activity history.
For example, a procurement team may receive requests through email and chat. A first internal tool can provide a request form, a queue, an owner, and a “needs clarification” status. It does not need to replace the ERP, calculate every purchasing limit, or cover every branch immediately. A small process with a clear owner is often more useful than a large dashboard no one maintains.
How to choose a first scope
Start with one outcome and one user type. Use this sentence: “[role] must [action] so that [result], using [data].” For example: “A visitor must choose a pump by flow and pressure so they can send an enquiry, using published specifications and availability.”
Then answer five questions:
- Who opens the product first: anyone, a known client, or an employee?
- Which action proves value: an enquiry, selection, download, status check, or approval?
- Which data is required for that action, and what can wait?
- Who owns the data and fixes an error?
- What happens when a source, employee, or user is unavailable?
Build a testable slice next. For a website, use one offer and one form. For a catalog, use a small set of representative products, including edge states. For a portal, use one request type and one role. For an internal tool, cover one process from creation to completion.
The Fluw workflow is designed to put an early result in the browser so a team can inspect pages, forms, data, and actions. Use pricing to compare the intended scope, and mark any integration or special logic that needs a separate assessment.
Selection checklist
- The primary user role is named.
- One primary action is written down.
- Every required field has a source.
- A data and error owner is assigned.
- Permissions and sensitive data are identified.
- Empty, stale, and unavailable values have a defined behavior.
- The first slice can be tested without the full assortment or every department.
- The user has a clear next step after the action.
Common failure modes
Starting with the format name. “Build a portal” says nothing about the first user action. Start with the user journey.
Copying every field. A complete export is not automatically a useful model. Connect fields that help someone choose, request, check, or approve.
Mixing public and internal roles. An employee may see a purchase cost that a visitor must not. Separate audiences before designing screens.
Promising a connector by system name. Check access, API, fields, limits, and refresh expectations first. Label sample data as demonstration data.
Automating exceptions before the main path. Confirm the normal process and its owner before adding rare cases.
Frequently asked questions
Can a website and catalog be combined?
Yes. The website can explain the offer and lead into the catalog, while the catalog supports product selection and enquiries. For the first release, decide where the main value moment happens.
Do we need a portal if we already have a form?
Not necessarily. A one-time request with an email response may only need a form. A portal earns its place when users return for statuses, documents, or history.
How is an internal tool different from a CRM?
An internal tool can cover one process or role without replacing a CRM, ERP, or accounting system. Define what it reads, what it changes, and where the source of truth remains.
What if we do not know the format yet?
Describe the user, their recurring question, and the data you already have. Then start with a task in Fluw and inspect a first result in the browser instead of debating the label in the abstract.
The right format is not the largest feature set. It is the shortest path from a real user need to a clear next action. Start with one route, assign ownership, and test it against a real working example. You can then expand a website, catalog, portal, or internal tool without losing the reason it exists.