By: Fluw editorial team
Published: 4 September 2026
Website cost starts with the result, not the mockup
“How much does a website cost?” sounds like one question, but it can describe several different outcomes. A small company site with approved copy and images is one project. A catalog that displays products from a spreadsheet or accounting system is another. A client portal with documents and statuses adds access rules and operational ownership. One number before the result is defined usually creates a false sense of precision.
Fluw helps companies create websites and web services that use their own data: landing pages, catalogs, online storefronts, client portals, and internal tools. The scope is shaped not only by the number of screens, but by what a visitor must do, which data they can see, and who will maintain it after launch. Current options belong on the live Fluw pricing page; this article gives you a framework for comparing those options with your task.
Three levels of outcome
A content-led website
This may be a landing page or company site with copy, images, contact details, a form, and a clear next step. The main cost factors are the amount and readiness of content, page structure, visual direction, responsive behavior, forms, and publication requirements.
If copy is approved, images have the necessary rights, and the page list is clear, the work is easier to estimate. If material must be gathered from decks, email threads, and an old website, the scope includes editorial decisions: what is still true, how sections should be named, and which claims need approval.
A catalog or online storefront
A catalog adds records: products, categories, attributes, prices, images, availability, and display rules. First identify the source of truth. It may be a spreadsheet, file, accounting system, or CRM. Then decide whether updates are manual, scheduled, or delivered through a verified connection.
Source quality changes the work. Each record needs a stable identifier, a clear name, and an agreed price format. Images should match products, categories should have a consistent meaning, and empty values need a rule. If one column contains “available,” “in stock,” and “ask us,” the data model is not ready until those terms are reconciled.
The connected catalog example shows how a source, field mapping, and final card can be presented. It is a demonstration using test data, not a promise of a ready connector for every system.
A portal or internal service
A client portal can add users, roles, documents, statuses, requests, and activity history. An internal tool may include forms, approvals, directories, and work queues. The important work is not only visual: define who can see a record, who can edit it, what happens after submission, and how the next step is restored when something fails.
When data is personal or commercially sensitive, the scope also includes access checks, field boundaries, session behavior, and revocation. Separate verified security practices from work that needs its own assessment before treating a requirement as included.
Cost factors that actually change the scope
1. Content and structure
How many pages are needed? Who writes the copy, selects images, and approves changes? One coherent content set reduces uncertainty. Several competing structures, legal constraints, or frequent review rounds add decisions before acceptance.
2. Data quality
Data is not just a file to upload. You may need to check fields, duplicates, category relationships, price formats, units, images, and update dates. The closer the source is to an agreed model, the less manual checking the first release needs.
3. Sources and integrations
If a site reads from another system, scope depends on its API, available methods, limits, permissions, response format, and outage behavior. “Connect our CRM” does not describe an integration. A file import may be enough for a first version; reading, writing, or two-way status exchange may need a separate technical assessment. See when a website needs a CRM or accounting connection for a fuller checklist.
4. Roles and user actions
A public page, a client portal, and a manager view can use the same records while requiring different permissions. Describe roles with verbs: a client views and submits a request, a manager checks it and changes the status, a lead approves it. Every extra action needs a rule, a check, and an error path.
5. Payments and orders
Showing a price and accepting an enquiry is not the same as taking a payment. A payment flow can include a cart, delivery, taxes, refunds, order confirmation, status changes, and reconciliation with the primary system. If payment is not needed to test demand, do not silently include it in the first scope. Define what happens after payment and who handles an exception.
6. Acceptance and the definition of done
The result should be testable. List which pages open, which fields are required, what each role sees, where a price comes from, how an empty value appears, and where a request arrives. Also record exclusions, such as a new connector, a historical import, or automatic payments.
7. Ownership after launch
A website does not end at publication. Who updates copy, owns the source data, reviews access, and accepts changes? A catalog that changes every week needs an update process. A team launching a new page each quarter may care more about a clear content structure and the ability to continue without preparing the whole project again.
A simple pre-start cost framework
Answer these seven questions:
- What must the visitor do: read, choose, order, request a quote, download a document, or check a status?
- Which data is actually needed, and which fields must not be exposed?
- Where is the source of truth for copy, price, availability, customer, and status?
- What condition is the data in today: an approved file, scattered spreadsheets, or an available API?
- Is the site read-only, or must it also write a request, order, status, or document?
- Which roles are involved, and who owns the next step?
- Who will update the data and approve changes after launch?
Short, agreed answers make an estimate more reliable. If each stakeholder describes a different website, start with a small clarification phase. That is not bureaucracy; it prevents everyone from paying for a result that was never defined in the same way.
Failure modes that make a budget grow
Starting with a screen count. Ten screens do not say what a person does on them. Start with actions and data, then choose the pages that support them.
Reducing an integration to one label. “Connect the CRM” could mean reading contacts, delivering a request, or exchanging statuses. Specify fields, direction, and refresh behavior.
Treating a spreadsheet as a clean source of truth. It may contain duplicates, old prices, or unmatched images. Assign a data owner and record the export date.
Leaving roles until the end. If a client, manager, and approver all see the same thing, the portal may not solve the work. Define permissions before implementation.
Adding payments just in case. Payment adds checks and responsibility. If it is not required for the first version, make it a separate stage.
Skipping acceptance criteria. Without testable criteria, review becomes an endless “not quite.” Agree on examples, required fields, test roles, and the correction rule.
A cost-planning checklist
- One primary outcome and CTA are written down.
- Pages and user actions are listed.
- Content is collected and image rights are checked.
- Data has an owner, date, and understandable format.
- The source of truth and minimum field set are agreed.
- An integration is described separately from a file import.
- Roles, permissions, and post-form actions are listed.
- Payments, orders, and refunds are included or explicitly excluded.
- Acceptance includes testable examples.
- Someone owns updates after launch.
Frequently asked questions
Why can’t price be based on page count alone?
Because two pages can carry very different rules. An article and a status-based portal require different decisions, checks, and ownership. Cost should reflect the outcome and data, not only the number of screens.
Can we start with a simple site and add a catalog later?
Yes, if the first structure and materials can be reused. Start with a clear outcome and make the catalog or system connection a separate, testable stage.
What should we prepare for an integration assessment?
Bring the user action, a sample API response or file, the field list, permissions, refresh expectations, and outage behavior. A system name by itself is not enough.
Is ongoing support included?
That depends on the selected option and scope. Agree on who updates content and data, how changes are accepted, and which work is assessed separately. Use the live pricing page, not an old copy of prices in an article.
Do we need a developer?
Not to describe an ordinary task, review the result, or change common content and layout. Separate technical help may be needed for a new integration, payment flow, or critical custom logic.
Start with a clear task
You do not need a perfect technical brief. Describe who comes to the site, what they choose or submit, which data they need, and who owns the next step. Add a sample of the materials and source. See how Fluw works, review the live pricing, and start with a task. The conversation can then be about a verifiable result rather than a random number for “a website.”