Back to insights

Website development cost: what should the proposal include?

What affects website development cost, which items are one-off or recurring, and how can two proposals be compared?

Kristóf Borbély
Kristóf BorbélyPublished: Updated:

AT A GLANCE

There is no single price for every website project: scope, content work, custom functions, integrations, and handover conditions determine the cost together. A comparable proposal names these items, separates one-off and recurring costs, and explains how changes will be handled.

  • List the pages, functions, and integrations that will be delivered.
  • Separate one-off work from recurring costs after launch.
  • Define handover, access ownership, and change handling.

1. What affects website development cost?

Cost is mainly shaped by the number of pages and language versions, copy and image work, custom design, forms and integrations, migration of existing content, and the agreed testing and handover scope. A simple company website and a multilingual site connected to other systems are not the same job.

Instead of comparing headline totals, ask for the defined scope, one-off development items, costs that continue after launch, and what counts as an additional request. A responsible price can be given when these points are clear; a generic market range cannot replace a proposal for the actual brief.

2. What exactly will be delivered?

The proposal should name page types and quantities, such as a home page, service pages, contact page, knowledge base, or language versions. A “modern company website” is not a scope. Forms, search, booking, payment, and external integrations should be listed separately.

It should also state what is excluded. A later customer portal, product import, or additional language should not silently expand the original work. Two proposals are comparable only when they describe the same defined outcome.

3. Who supplies content, images, and access?

Record who writes and approves copy, supplies images and logos, provides legal text, and grants access to required accounts. If copywriting, photography, translation, or image licences are separate work, show them as separate items or explicit exclusions.

Client responsibilities affect timing. The proposal should say which materials are needed and when, and what happens if they arrive late or incomplete. Content awaiting approval can stop a project as completely as a technical problem.

4. What counts as complete and accepted?

Handover conditions should be testable. They may cover approved pages working on mobile and desktop, form delivery, agreed search basics, measurement and consent settings, and the agreed browser and accessibility checks.

The proposal should also define review and approval rounds. Correcting a defect is different from adding a new requirement. Without this distinction, neither side can tell what remains inside the original commitment at handover.

5. Who owns the domain, hosting, and access?

Domains, hosting, analytics, and other business services should normally be registered to or controlled by the client. State who creates each account, who pays its fees, and which administrative access the client receives at handover.

Clarify usage rights for source code, templates, fonts, and images, including licences. Handover may include an access inventory, backup, short operating guide, and a named route for support when something fails.

6. Which costs continue after launch?

Alongside design and development, list every known recurring item that applies to the chosen solution: hosting, domain renewal, paid software, email delivery, maintenance, and support. Not every project needs every item, so the proposal should describe actual costs rather than a generic package.

Payment stages, milestones, and the pricing method for additional work should also be clear. This makes it possible to compare the full first-year commitment and scope, not just two headline totals.

7. How should two proposals be compared?

Create one shared list of expected pages, functions, content tasks, handover access, post-launch fees, and dates. For each proposal, mark whether an item is included, separately priced, or undefined. Ask about missing entries before making a decision.

A lower total is genuinely better value only when it covers the same work, acceptance conditions, and handover. If one proposal omits content entry, measurement, or access ownership, make those differences visible first.

Sources and further reading

Kristóf Borbély

Kristóf Borbély

The developer behind Kriside, writing practical guides about web systems, automation, and AI solutions.

IT STARTS WITH A CONVERSATION

You need more than another tool.
You want a system that works.

Tell us how your team works. We will explore where things could be simpler.

Show us what slows you down