[email protected]CONNECT • BUILD • GROW
WEBSITE DESIGN

What Should Be Included in a Website Design Quotation?

A useful quotation specifies pages, responsive requirements, content responsibility, revisions, integrations, hosting/domain arrangements and handover.

OnHypp Editorial · 12 min read
Purple and lavender editorial browser illustration representing website design.

The decision for a small business

A useful quotation specifies pages, responsive requirements, content responsibility, revisions, integrations, hosting/domain arrangements and handover. It should distinguish one-time design from recurring maintenance or subscriptions.

An illustrative small-business scenario

Consider this hypothetical situation: Two quotations both say 'five pages'. One includes content writing and testing; the other excludes both. Their totals are not comparable until scope is normalised.

The point is not that every business has the same needs. For what should be included in a website design quotation, first identify the real decision, the person responsible and which evidence will show that the selected option worked.

How to plan it

Ask who supplies text and images, whether blog setup or forms are included, how approval works, and what support period follows launch. Request itemised treatment of extra work.

Limits to understand

A low starting price is not a complete project total. Evaluate the exact signed scope; avoid assuming custom systems, unlimited revisions or SEO results are included.

A practical next decision

Ask the designer to specify page count, content responsibilities, revisions, ownership of assets, mobile checks, SEO basics, hosting and aftercare. Distinguish one-time build work from recurring fees. A low headline price is difficult to compare unless deliverables and exclusions are written.

Define the outcome before asking for a price

A quotation should begin with the business problem the website is meant to solve, not a vague promise of a modern design. Record the primary audience, what visitors must learn, and the action they should be able to complete. A repair business may need service-area information and an enquiry route; a distributor may need a searchable catalogue without online checkout. Ask the supplier to restate these outcomes in the proposal. Otherwise two attractive mock-ups may hide very different functionality and the buyer cannot judge whether delivery is complete.

Specify a page inventory rather than only a page count

A five-page package is ambiguous until the quotation names the pages and describes their purpose. Ask for a page inventory such as Home, Services, About, Contact and a policy page, with the expected sections and approximate content complexity. A service directory with filters is not equivalent to a simple text page. Clarify whether each language counts as a separate page, whether blog posts are included, and how future additions are priced. A written inventory prevents a dispute over whether a requested page was part of the agreed scope.

Distinguish templates, configuration and bespoke development

The words custom website can refer to many levels of work. A supplier might configure a licensed theme, adapt a reusable component system, or design and code new interfaces. None is automatically better for every small business. Request the proposed platform, design method, reusable components, licensing dependencies and limitations on later modification. If a unique booking workflow or database is required, describe it separately with acceptance criteria. A visual redesign does not imply that a supplier is building a new application or transferring exclusive rights to underlying tools.

Name the person supplying every piece of content

Website work often stalls because the designer expects approved text while the client expects copywriting to be included. List who provides company facts, service descriptions, photographs, testimonials, product specifications, policy wording and translations. Specify whether the supplier edits grammar, writes original copy from an interview, or merely uploads supplied material. Establish deadlines for owner approval and a method for marking facts that require verification. Do not allow invented customer endorsements or stock images presented as real projects. Content responsibility belongs in the quotation because it changes both cost and schedule.

Treat English and Bahasa Melayu as separate deliverables

A bilingual website requires more than a language switch graphic. Specify which pages will exist in English and Bahasa Melayu, who writes or adapts each version, and who checks meaning, terminology and commercial accuracy. Agree on navigation labels, contact details, forms and error messages in both languages. Ask whether adding a new page later includes two language versions. Google documents distinct language URLs and signals such as hreflang for localized pages; these are technical considerations, not a promise of rankings. Independent language review must be quoted explicitly rather than silently assumed.

Define brand inputs and image permissions

The quotation should identify approved logos, colours, fonts and tone-of-voice material that the team will use. Ask whether the supplier creates new graphics, optimises existing photographs or licenses third-party imagery. Record who pays for licenses, whether rights continue after the contract, and whether source files are delivered. A client photograph may contain staff, customers, vehicles or confidential screens; permission and suitability should be checked before use. Avoid a blanket statement that every image becomes the buyer's property when the work includes third-party assets with their own terms.

Make responsive behaviour testable

A quotation saying mobile-friendly should explain what will be checked. Request layouts for narrow phones, tablets and desktop widths, including navigation menus, long headings, tables, buttons and contact links. Specify the browsers and devices that will be sampled, and whether portrait and landscape layouts are included. The supplier should demonstrate that visitors can read text and complete core tasks without accidental horizontal scrolling or overlapping controls. Responsive design is not a guarantee that every device ever manufactured will behave identically; define a practical supported testing matrix.

Specify accessibility goals and evidence

Accessibility should not be reduced to a plugin badge or a colour preference. W3C's WCAG guidance addresses perceivable content, keyboard operation, understandable interfaces and compatibility with assistive technologies. Agree on the target standard or selected criteria, who prepares alternative text and captions, and which manual checks will be performed. Keyboard navigation, visible focus, labelled form fields and meaningful link text are useful acceptance examples. Automated scanners can flag some issues but cannot certify all user experiences. A formal conformance claim requires appropriate evidence and should not appear by default.

State performance work without promising a fixed score

Ask whether the scope includes image compression, appropriate dimensions, caching, script review and basic page-weight checks. Google describes Core Web Vitals as measures of loading, interaction and visual stability, but scores vary by page, device, connection and real visitor data. Specify representative pages and the test environment, then decide what constitutes an actionable defect. A single laboratory screenshot should not be sold as a permanent speed guarantee. Hosting capacity, third-party embeds and later content updates can affect results after handover.

Separate foundational SEO from ongoing search marketing

A website build may reasonably include descriptive page titles, headings, crawlable navigation, image alternative text and sensible internal links. It does not automatically include keyword research for dozens of topics, editorial campaigns, backlink outreach or continuous ranking reports. Ask which technical items will be delivered, how sitemap and robots directives are handled, and who verifies indexing eligibility. Google explicitly does not guarantee that every eligible page will be indexed or ranked. Any promise of first-page placement should be challenged rather than treated as a standard design deliverable.

Describe every enquiry form and its destination

A contact form is not complete merely because its fields appear on screen. List the fields, required indicators, validation messages, confirmation state, destination mailbox or storage system, spam controls and failure behaviour. MDN explains client-side validation, but it cannot replace secure server-side processing where a backend is involved. Ask who tests a real submission and verifies receipt, who maintains the receiving address, and how personal information is handled. If the quotation excludes backend integration, label the form as a visual prototype until a working service is separately commissioned.

Identify integrations and the limits of each

A map embed, messaging link, payment gateway, booking calendar and customer relationship system have different dependencies. List each integration by name, its expected behaviour, who owns the account, and whether setup fees or subscriptions are excluded. A button opening a messaging app is not the same as a staffed support workflow. Payment acceptance requires more than a styled checkout screen. Specify how errors, unavailable services and provider changes are handled. Any integration involving credentials or personal data needs a separately reviewed security and access plan.

Keep domain, DNS and hosting as separate line items

Domain registration, authoritative DNS, web hosting and business email can be purchased from different suppliers. A quotation should state which components are included, whose account holds each one, the initial term, renewal responsibility and any migration work. Avoid assuming a free first-year domain means indefinite ownership or that website hosting automatically includes mailboxes. Record who can change nameservers and who receives expiry notices. Where an existing website or email service is active, any migration requires a dependency map and explicit cutover approval rather than an unannounced DNS change.

Clarify the content management arrangement

Some websites are edited through a content management system; others require changes to source files or a supplier's proprietary editor. Ask which fields the owner can update without technical assistance, how accounts are protected, and whether training is included. A content editor may permit text and image changes while restricting templates or custom code. Confirm whether plugins, themes and editor licenses carry renewal costs. If the client expects to publish news weekly, the quotation should describe that workflow and permissions rather than merely say the website is editable.

Make security responsibilities visible

A design quotation should not imply that an attractive interface is secure by itself. Identify who provisions HTTPS, manages software updates, restricts administrator access, handles backups and responds to security incidents. The OWASP Top 10:2025 highlights categories including broken access control, misconfiguration and software supply-chain failures; which controls apply depends on the website's architecture. A static information site and a login-enabled application have different risks. Require a documented owner for each operational control and distinguish initial configuration from ongoing monitoring or emergency response.

Require a defined review and revision process

Unlimited revisions is not a reliable scope definition. Ask how many design concepts and revision rounds are included, who consolidates feedback, what counts as a correction versus a new request, and how long the client has to respond. A change to a spelling mistake differs from adding a new booking system after design approval. Establish a decision maker and a record of approved screens or content. The quotation should explain the cost and schedule effect of late changes, not leave the supplier or buyer to guess.

Set milestones and dependencies, not only a launch date

A credible schedule identifies discovery, content receipt, design review, implementation, testing, owner acceptance and release readiness. It also records dependencies: approved copy, image permissions, access to a staging environment and timely decisions. A promised delivery date is difficult to evaluate when the client has not yet supplied essential materials. Ask what happens when a dependency is late and whether a milestone is deemed accepted automatically. Distinguish completing the source files from publishing the website; production deployment should remain a separately authorised step.

Agree on staging, acceptance tests and evidence

Ask for a private review location where the client can inspect representative pages before publication. The quotation should describe tests for links, navigation, images, responsive layouts, language switching and contact routes. For forms, a simulated click is not evidence of delivery to the intended mailbox. For accessibility, a scanner result is not the same as manual keyboard testing. Record defects with screenshots, reproduction steps, severity and ownership. Acceptance should refer to agreed deliverables and observed outcomes, not the subjective impression that the site looks finished.

Separate initial launch work from production authority

Some suppliers include deployment in their package while others deliver source files for the client's team to release. Identify who controls the hosting account, who takes a backup, who approves the cutover, and what rollback is possible. The quotation can include a launch checklist without authorising an immediate live change. For an existing business website, changing DNS or replacing files can affect email, redirects and customers. A written go/no-go decision and tested recovery procedure are safer than treating design approval as deployment permission.

Describe ownership, handover and portability

Ask exactly what will be handed over: domain account details, hosting administration, content files, licensed assets, source code, repository access, documentation and training notes. Distinguish materials owned by the buyer from reusable supplier libraries and third-party licenses. If a subscription ends, can the client export content and move to another provider? What happens to images, database records and redirects? A supplier may legitimately retain rights in its general tools; the quotation should make that boundary visible before the project starts.

Specify maintenance and post-launch support separately

A website needs an owner after handover even if its initial design is complete. Ask whether the price includes a defect-correction period, content updates, backups, monitoring, software patches, domain renewals or emergency support. Each activity has different effort and response expectations. A thirty-day correction period, for example, is not automatically a promise of unlimited feature requests or round-the-clock availability. Define support hours, communication channel, escalation route and what constitutes chargeable new work. Do not assume the design fee covers indefinite maintenance.

Compare the complete cost over the relevant term

To compare suppliers, create a side-by-side table covering initial design, copywriting, translation, photography, hosting, domain, licenses, integrations, maintenance, taxes if applicable and renewal terms. Use only verified written figures; do not fill unknown cells with zero. Ask whether the quoted amount is fixed, estimated or conditional on the final brief. Record deposit and milestone-payment triggers without assuming any particular commercial policy applies. A cheaper initial build can cost more later if every small edit requires paid assistance. Compare total obligations and useful outcomes, not just the headline number.

Identify exclusions and the process for changes

A useful exclusion list is as important as the inclusion list. It might state that e-commerce, payment processing, custom APIs, bulk data entry, legal drafting, professional translation, ongoing SEO and marketing campaigns are not part of a simple information-site quote. The supplier should explain how an additional requirement is estimated and approved before work starts. Exclusions should be specific enough to prevent surprise, not a broad clause that negates every promised deliverable. Keep the final accepted scope attached to the quotation or contract so later conversations do not silently rewrite it.

Use a concrete acceptance example

Consider a hypothetical local service company requesting a bilingual site with Home, three service pages and Contact. A useful quote would state ten language-specific page versions if each of those five pages is supplied in both languages, who writes each version, which forms actually send messages, and which devices are tested. It would list separate annual hosting and domain obligations and identify the owner of all accounts. If one supplier excludes translation and another includes it, adjust the comparison rather than concluding that the lower total buys the same result.

Finish with a decision record, not a vague approval

Before accepting a quote, ask the supplier to attach the page inventory, responsibilities, exclusions, schedule, payment conditions, acceptance checklist and handover list. Mark unresolved items as questions rather than assumptions. Confirm which document prevails if an email conflicts with the signed scope. Keep a dated copy of the accepted version and record who may authorise paid changes. This discipline does not guarantee a flawless website, but it makes problems easier to identify, price and resolve without confusing design preference, functional defects and new business requirements.

Separate the website build from its hosting environment

A quotation for a website design should define the actual deliverables: number of pages, content provision, revisions, contact forms, publishing access and acceptance tests. Website hosting is a recurring operational service; application installation and long-term software maintenance are different responsibilities again. Where an online store, booking system or HR portal is included, ask for the supported application version, backup scope, admin access and update policy rather than assuming those services are covered by an ordinary design fee.

OnHypp's default Biz/Power bundles remain available for normal website and business email requirements. They are not alternative prices for a complete e-commerce build, Gibbon deployment or ongoing application support. In a useful quotation, show the agreed website-development fee, the chosen annual hosting package, any email service and application-care responsibilities without counting the included qualifying domain twice.

Sources & further reading

Ready to explore a related service?

See the related OnHypp service and decide whether it fits your business needs.

Website designEmail & hosting