A professional website does not have one fixed price. The proposal depends on its objective, number of templates and pages, state of the content, design, features, languages, integrations and who will handle ongoing maintenance.
Giving a figure without knowing those variables would turn an estimate into advertising. A useful answer to how much a website costs explains which work is included, which costs continue after launch and which decisions reduce or expand the scope.
Why an isolated price range says so little
Two projects described as a “five-page business website” can require very different amounts of work.
In one, the client supplies finished copy, photography and a prepared visual identity. Every page shares a structure and the only form sends an email.
In another, the services need to be organised, copy needs to be written, custom components must be designed, two languages prepared, old URLs migrated, a booking tool connected and measurement configured. The page count may be similar, but the work is not.
A published range without a defined scope also cannot tell you whether it includes taxes, content, licences, hosting, maintenance or support after launch. I would therefore compare proposals by deliverables and responsibilities, not only by their final figure.
The objective defines the first level of scope
Before counting pages, decide what the website must achieve.
These projects do not require the same approach:
- Presenting one service and receiving enquiries from a campaign.
- Explaining several professional services and building organic visibility.
- Selling products with payments, stock and customer accounts.
- Managing bookings or private areas.
- Migrating an existing site without losing important URLs.
- Publishing content independently through a CMS.
One concentrated offer may be served by a landing page. A business with several needs usually requires architecture, navigation and different templates. The comparison between a landing page and a full website helps establish that first boundary before requesting prices.
What work a professional website can include
A solid proposal does not charge only for writing code. It may bring together several phases:
| Area | Possible work |
|---|---|
| Discovery | Goals, audience, priorities, constraints and scope |
| Architecture | Page map, navigation and content hierarchy |
| Content | Copywriting, editing, image selection and translation |
| Design | Visual direction, components, states and responsive adaptation |
| Development | Templates, components, forms and behaviour |
| Integrations | CMS, bookings, CRM, payments, email or external services |
| Initial SEO | Metadata, indexation, sitemap, internal links and structured data where appropriate |
| Quality | Accessibility, performance, browsers, devices and error review |
| Launch | Domain, deployment, analytics, documentation or training |
| Continuity | Maintenance, support, content and later improvements |
Not every project needs every item. What matters is that the proposal states which ones are included, who owns each responsibility and what will be treated as additional work.
Pages and templates are not the same thing
The number of pages matters, but the number of different structures often explains design and development work more accurately.
Ten articles can use one template. By contrast, a home page, service, project, search, contact and private area may need six different structures, states and tests even with fewer URLs.
When defining scope, it helps to separate:
- Unique pages such as the home page.
- Reusable templates such as services or projects.
- Entries that use those templates.
- Special states: empty, error, loading, confirmation or validation.
This distinction avoids charging for every URL as if it started from nothing. It also prevents work requiring its own design from being estimated as simple repetition.
Content can change the price considerably
Development progresses differently when copy and assets are ready than when each page still needs to discover what it should say.
Agree on who will:
- Write and review the copy.
- Translate and validate it in every language.
- Produce photography, illustration or video.
- Supply usable logos and brand files.
- Load the content into the website.
- Approve versions within an agreed timeframe.
Designing with real content reduces surprises. Designing with generic blocks first and receiving copy three times longer later usually forces another review of hierarchy, components and responsive behaviour.
Supplying the material does not automatically mean it is ready. It may still need editing, image compression, alternative text or format changes. My guide to preparing images for the web explains part of that work.
Custom design versus an existing foundation
An identity and component system created for the project require more decisions than adapting an existing template. That custom work can be justified when differentiation, brand or a specific interaction matters.
A reusable foundation can reduce time when it fits the content and does not force the website into the wrong shape. Problems appear when a template is chosen for its price and then has to become something it was not designed to be.
The proposal should clarify whether it includes:
- Design from scratch or adaptation.
- Mobile, tablet and desktop versions.
- Interactive states and error messages.
- A reusable component system.
- The number of concepts or review rounds.
- Editable files and usage terms for external assets.
Features and integrations
Every feature adds more than a screen. It can also add validation, errors, permissions, external services, privacy considerations, testing and maintenance.
Examples include:
- Forms with logic or file uploads.
- Bookings and calendars.
- Payments and invoicing.
- Catalogue, stock and shipping.
- Private areas and authentication.
- Search and filters.
- A CMS for editing content.
- CRM, newsletter or automation tools.
- Analytics and consent management.
- Data from external APIs.
Requesting “a form” does not define the effort. A name, email and message form is not the same as a multi-step application with documents, conditional rules and a CRM connection.
Integrations also depend on third parties. You need to know whether they require a subscription, who controls the account and what happens if the provider changes its service.
Languages, SEO and migrations
A bilingual website is not only duplicated text. It needs validated content for each language, coherent routes, metadata, navigation, hreflang alternates and tests for every journey.
Initial SEO also changes with the project. A landing page addressing one intent does not require the same research and architecture as a multi-service website with a blog.
A redesign may also need to:
- Inventory existing URLs.
- Decide which content to retain, combine or remove.
- Prepare redirects.
- Preserve relevant metadata and links.
- Review crawl errors after launch.
Google’s site migration guidance recommends mapping old URLs to new ones, updating links and sitemaps, applying permanent redirects where appropriate and monitoring the move. These are specific tasks that belong in scope when URLs change.
Ignoring this phase can reduce the initial proposal and make later corrections more expensive. The quote should state whether migration and post-launch monitoring are included.
Initial cost, recurring costs and maintenance
I would separate the total cost into three groups.
1. Initial creation
This covers the agreed work to research, design, develop, test and launch the website.
2. Recurring services
These may include the domain, hosting, email, licences, CMS, booking, analytics or other external tools. Some have a free plan; others charge by usage, features or number of users.
The proposal should state which accounts the client contracts directly and which depend on the provider. Wherever possible, the business should retain control of its main accounts and access details.
3. Work after launch
Maintenance does not mean the same thing in every contract. It may cover updates, backups, issue reviews, support, small changes or new features. If there is no ongoing agreement, it helps to know how future work will be quoted.
A static website and an installation with a CMS, plugins and a database also have different operating needs. In Astro versus WordPress I explain how editorial independence and maintenance affect the technical choice.
What a website proposal should include
Before accepting a proposal, I would check that it covers at least these points:
- Project objective and scope.
- Included pages, templates and features.
- Responsibility for copy, images and translations.
- Planned technology, CMS and integrations.
- Included SEO, accessibility, performance and analytics work.
- Number and process of review rounds.
- Schedule, milestones and client dependencies.
- Price, taxes and payment terms.
- Third-party costs and renewals.
- Ownership of the domain, accounts, content and delivered code.
- Error warranty, support and later maintenance.
- Exclusions and the process for pricing scope changes.
A clear proposal protects both parties. The client knows what they will receive, and the professional can distinguish an included correction from a new request.
How to compare two proposals
First, check that both solve the same problem. One proposal may include strategy, content and maintenance while another only builds the visual layer using supplied copy. Comparing only the total would hide that difference.
Then review:
- Which deliverables appear in writing.
- What you need to supply and by which dates.
- Which costs continue every month or year.
- Who controls the domain, hosting and accounts.
- How reviews and new requests are managed.
- What happens after launch.
I would also ask for relevant examples, not only attractive screenshots. A case study should make the context and work understandable. The Patricia Pólvora project shows how I document scope and decisions without presenting unverified metrics.
How to reduce scope without weakening the website
If the proposal exceeds the available budget, I would reduce it by priority rather than basic quality.
Reasonable options may include:
- Launching the main service first and expanding later.
- Preparing copy and images internally with clear guidance.
- Using fewer templates and more reusable components.
- Postponing integrations that do not yet support a validated process.
- Starting with one language while planning the second properly.
- Choosing code-based editing when a CMS is not needed.
- Dividing the project into phases with clear objectives.
I would not remove mobile testing, essential accessibility, basic security or indexation settings to reach a figure. They are part of delivering a usable website, not finishing touches.
What I need to prepare a price
To turn an idea into a proposal, I need to know:
- What the business does and what the website must achieve.
- Which services, products or content it needs to present.
- Who it is for and how traffic will arrive.
- Whether a website, brand, copy and images already exist.
- Which features and integrations are essential.
- Which languages it needs.
- Who will update the content.
- Which date, constraints and indicative budget exist.
With that information, I can propose a scope, separate essentials from optional work and explain what the price includes. Without it, any figure would be an assumption.
My web design and development service for professionals and businesses explains the working process. If you have already defined the project, you can email me with the goal, content and features you need so I can prepare a proposal.