Commissioning a hotel website: cost lines, comparing quotes and the contract

A hotel website cost is the sum of seven separate lines: design and build, content in each language, photography, the booking engine, hosting and domain, maintenance, and search setup. Quotes differ because they cover different lines. Compare them line by line on the same scope, then settle ownership of the domain, content and code in the contract.

Three quotes for the same hotel website arrive, and the totals sit far apart with no explanation attached. The gap is rarely the design: it is what each quote quietly includes, and what it quietly leaves for later. This guide breaks the purchase into its cost lines, shows how to write a one-page request that makes quotes comparable, and lists the contract terms that decide who owns the site when the relationship ends.

What are you actually buying when you commission a hotel website?#

You are buying seven separate things that one total hides: design and build, content, photography, the booking path, hosting and domain, ongoing maintenance, and search setup. Each has its own supplier, its own timing and its own way of going wrong. A quote that shows one number has already made seven decisions for you, silently.

Design and build covers the page templates, the mobile layout, page speed and the agreed page list. Ask for the page list in writing, because a quote built on six pages and a request built on twelve are different projects. Content covers who writes the text, in which languages, whether it is translated or written natively, and who approves each version before it goes live.

Photography covers shoot days, retouching, file formats and image rights. A site that launches with the hotel's own phone photos will be rebuilt sooner than the owner expects. The booking path covers the engine, the payment method, the confirmation message and the connection to the hotel's own system: this is the line most often assumed rather than quoted. Hosting and domain covers whose account holds them, who renews, who pays, and what happens on the day a renewal is missed. Maintenance covers security updates, small text and rate changes, response time, and whether it is billed monthly or hourly. Search setup covers page titles, site structure, a sitemap, analytics, and whether ongoing search work is inside the fee or outside it.

Ready-made template, website builder or custom site: how do you choose?#

Choose the simplest route that still carries your page list, your languages and your booking path. A template becomes a problem at the moment it forces a booking path you cannot change. Cost alone should not make this decision: fit does.

A ready-made template delivered by an agency gives a fixed design, the agency does the setup, and changes are billed afterwards. Check whether the template is licensed per site and who holds that license. A hosted website builder lets the hotel edit its own pages for a monthly fee; check what can be exported and what stays behind if the hotel leaves. A custom build is the highest cost line, and it earns its price when the site must connect to the hotel's own systems or carry a structure that templates do not support.

The decision rule is mechanical: count the languages, count the pages, list the connections the site needs, then see which route covers all three without custom work. Judge the mobile layout and the page speed on a phone before choosing, because most guests will meet the site there. Ask each route for its total cost over the same period, including the changes you already know you will need in the first year.

What should a one-page request to suppliers contain?#

One page, sent unchanged to every supplier, stating what the site must do, in which languages, connected to which systems, and what you expect after launch. The same request to everyone is what makes the quotes comparable later. Without it, each supplier prices the project they imagined, not the one you described.

The request opens with the page list, with one line on the purpose of each page, so suppliers price the same set. It states the languages: which ones, who writes each, who approves each, and what happens when a rate or policy changes in every language at once. It specifies the booking path: which engine, which payment method, what the guest receives after booking, and which hotel system the booking must reach.

It also names who supplies content and photography, and by which date, so the schedule shows your own dependencies as well as the supplier's. It states ownership: domain, content, images, code and every account in the hotel's name. It covers after launch: update policy, support hours, response time, what the monthly fee covers and what is billed hourly. It closes with one instruction: quote in the same line structure as this request, one line per item, and mark anything not included as excluded.

How do you compare hotel website quotes fairly?#

Fix the scope first, then compare: same page list, same languages, same booking path, same contract length, and the same ongoing costs over the same period. Until then, the totals are measuring different projects. A tenfold gap between quotes is almost always a scope gap wearing a price tag.

Rewrite each quote into your request's line structure. Where a line is missing, ask the supplier to confirm in writing whether it is excluded or included at no charge. Compare the total over the contract period, not the first invoice: a low build price with a high monthly fee inverts over two or three years. List what triggers extra billing: an additional language, an additional page, edits after approval, photo retouching, out-of-hours support.

Ask who actually does the work: the person in the meeting or a subcontractor, and who writes the copy. Get the timeline in writing with the hotel's own dependencies marked, such as approvals, texts and the photo shoot. Treat a very low total as a scope question rather than a bargain, and find the missing line before you decide, not after launch.

Is the booking engine part of the website or a separate cost?#

Usually separate. The website is the shopfront and the booking engine is the till, and they are often sold, billed and contracted by different companies with different terms. Treating the engine as a website feature is how hotels end up with a site that cannot reach their own reservations.

The engine shows availability and rates, applies the hotel's conditions, holds the room while the guest pays, and sends the confirmation. Billing models differ: a subscription, a fee per booking, or a share of each booking. Compare them on the same assumed booking volume, clearly labelled as an example, not a forecast. For example, a hotel expecting 200 direct bookings a year can put that number into all three models and compare the annual totals.

Ask where the guest record lands and who may use it afterwards, because that answer decides what the hotel can do with its own guest list. Ask what happens to the engine if the hotel changes website supplier, and what happens to the website if the hotel changes engine. Test the booking path end to end on a phone, including the confirmation message and the way a guest cancels. Read the engine's contract length and exit terms next to the website contract, since the two rarely end on the same date. For the questions to ask engine providers, see our guide on how to choose a hotel booking engine.

What should the contract say about domain, content, code and exit?#

It should name who owns the domain, the content, the images and the code, and it should describe how the hotel gets them and its accounts back if the relationship ends. A contract that is silent on ownership has, in practice, given the supplier the default position.

The domain should be registered in the hotel's name, with the registrar login held by the hotel, the renewal date written down and the payer named. Content and image rights should pass to the hotel on payment, and the source files are part of the handover, not an extra. On code, the contract should state whether the hotel receives ownership or a license, what happens to custom work, and whether the site can be moved to another host. Every account, hosting, analytics, search console and email, should be opened in the hotel's name, with the hotel's own address as the recovery contact.

Exit terms deserve their own paragraph: notice period, export format, a handover period with support, a final backup, and who keeps the redirects alive afterwards. Security and updates should state who applies them, who is responsible when something breaks, and what stops on the last day of the contract. Tie the payment schedule to handover items rather than calendar dates alone, so the final invoice follows proven access. For the underlying questions, see our articles on domain, certificate and login ownership and clauses to read in a hotel software contract.

What must be checked before the final payment?#

Prove access and completeness before the last invoice: logins, files, redirects and the booking path, each tested by someone from the hotel rather than by the supplier. A handover performed by the supplier is a claim; a handover performed by the hotel is a fact.

Log in to every account from a hotel device and change the recovery email to an address the hotel controls. Make a test booking, follow the confirmation, then cancel it, and check where the record appears in the hotel's own system. Check the live page list against the request, language by language, including the legal and contact pages. Confirm that the old site's addresses redirect to the new pages, so existing links and search results still land somewhere useful.

Receive the source files, the image rights and a full backup, and store them somewhere the hotel controls. Confirm the start date of the maintenance terms and what is covered inside them. Keep a written handover note that lists every account, who owns it and who holds the recovery address. For what the site itself should contain, see our hotel website checklist for content, legal pages and the booking path.

What to do next#

Write the one-page request before you ask anyone for a price, send the same page to every supplier, and compare only the quotes that come back in its line structure. Scope, route, request, comparison, contract and handover are one sequence: each step decides what the next one can contain, and the contract is where the earlier decisions are either protected or lost. Your next step this week is the page list: sit down with the front office, write every page the site needs and one line on why, and that list becomes the first line of the request.