Should You Build a Direct Booking Website in 2026? Pass the Break-Even Gate
The Break-Even Arithmetic
The cost comparison tells you a direct booking is cheaper per booking. It does not tell you whether the saving covers what the channel costs to build and run. That is a different question, it is arithmetic, and almost nobody does it before building.
Step 1: what you actually save per booking
Not the headline commission gap. Your gap. Take the fee you actually pay, which you can compute exactly using the host fee calculator, and subtract what a direct booking costs you in payment processing and booking-engine fees.
SAVING PER BOOKING
Saving = (platform fee rate − direct cost rate) × your average booking value
Both rates are yours, not published averages. The platform rate comes from your own fee notice. The direct rate is your payment processor's percentage plus any per-booking engine charge, expressed against the same booking value.
Step 2: what the channel costs you every year
| Line | Your figure | Note |
|---|---|---|
| Domain | $______ | Annual |
| Hosting or site platform | $______ | Annual |
| Booking engine or widget subscription | $______ | The recurring cost, not the setup fee |
| Channel manager, if you need one to sync | $______ | Often the largest recurring line |
| SSL, security, backups | $______ | May be bundled |
| Additional insurance, if your insurer requires it | $______ | Ask before you build, not after |
| Any paid acquisition you intend to run | $______ | If this is your demand source, it is a cost |
| Total annual recurring | $______ | Sum |
| One-time build cost | $______ | Amortise over your intended life, commonly 3 years |
| Your own hours to build, at your hourly value | $______ | The line people zero out. It is not zero. |
| Your own hours to maintain, per year | $______ | Recurring, and consistently underestimated |
Step 3: the number of direct bookings you need
BREAK-EVEN BOOKINGS
Break-even direct bookings per year = total annual cost ÷ saving per booking
Where total annual cost includes the recurring lines, the amortised build cost, and your own time valued honestly.
A worked example with stated assumptions
The inputs below are illustrative and invented. They describe no real host. Run yours.
| Input | Assumed value |
|---|---|
| Average booking value | $600 |
| Your platform fee rate | 15.5% |
| Your direct cost rate (processing plus engine) | 4.5% |
| Saving per booking = (15.5% − 4.5%) × $600 | $66.00 |
| Annual recurring cost | $1,140 |
| Build cost $1,800, amortised over 3 years | $600 |
| Your time: 30 build hours + 24 maintenance hours, at $40/hour | $2,160 first year |
| Total first-year cost | $3,900 |
| Break-even direct bookings, year one | $3,900 ÷ $66 = 59.1, so 60 bookings |
WHAT 60 BOOKINGS MEANS
At an average stay of 3 nights, 60 direct bookings is 180 direct nights in a single year. For a one-listing host that is a substantial share of a full calendar, arriving through a channel that had no traffic twelve months ago.
This is the number the cost comparison never shows you. It is also why the honest answer for most one-listing hosts is defer: not because a direct site is a bad idea, but because the saving per booking is capped by your booking volume while the cost is not.
Why the arithmetic favours multi-listing operators
Look at what scales and what does not. The saving is per booking, so it scales linearly with volume. Most of the cost is fixed: one domain, one site, one engine, one channel manager subscription tier, and roughly the same maintenance hours whether you run one listing or six.
That asymmetry is the entire economic case. A host with six listings crosses the same break-even on roughly the same fixed cost, with six times the booking volume feeding it. The question "should I build a direct site" therefore has less to do with your technical ability than with your booking volume, and it is worth being honest about which one is actually driving your interest.
A direct site is cheaper per booking only after it exists and works. This gate tests whether you can get it there.
The case for a direct booking site is usually made with a cost comparison, and the comparison is real. What it leaves out is the word that carries the whole argument: the lower cost applies once a working site and booking engine already exist.
Getting there is the project. This page is a gate on whether you can run that project and then operate what it produces, because a half built direct channel is more expensive than no direct channel at all.
TL;DR
- The reported direct cost of 4% to 5% assumes a working site and engine already exist.
- Reported commission on other channels runs 15% to 30% of booking value.
- A site does not create demand. It changes who you pay when demand arrives.
- Score payments, agreements, insurance, support, compliance and demand source first.
- Choose build, close prerequisites, or defer, and put a date on the choice.
Key facts this decision rests on
| Metric | Value | Source |
|---|---|---|
| Reported direct booking cost once a site and engine exist. | 4% to 5%. | Hospitality Net. |
| Reported OTA commission range for independent lodging. | 15% to 30%. | Hospitality Net. |
| Reported base commission most independent hotels pay. | 15% to 25%. | Hospitality Net. |
| Reported additional processing and currency charges. | one to three percent. | Hospitality Net. |
| Reported OTA cancellation rate in some markets. | up to 50%. | Hospitality Net. |
| Reported direct booking cancellation rate. | 18 to 20%. | Hospitality Net. |
Read the Cost Comparison with Its Condition Attached
Hospitality Net reports that direct bookings cost around 4% to 5% once a functioning website and booking engine are in place, against 15% to 30% of booking value for bookings through online travel agencies.
Once in place. That is the whole gate.
The reported cost of a direct booking after the site and engine exist and work. It is a figure for independent hotels, and it excludes building the thing it depends on.
The same reporting notes that processing fees and currency conversion charges can add one to three percent on top of a base commission, so neither side of the comparison is a single clean number.
A Site does not Create Demand
The most expensive misreading of the cost comparison is that a cheaper channel is a fuller one. It is not. A direct site changes who you pay when a booking arrives, not whether it arrives.
Cheaper per booking. Not more bookings.
Where direct demand actually comes from
Direct bookings come from guests who already know you exist. Repeat guests, referrals, and people who found you somewhere and chose to book straight through instead.
If none of those describes your current guests, a site will sit there. That is not a failure of the site. It is a demand source you did not have before you built it and still do not have after.
A booking engine converts demand. It does not manufacture it.
The Six Prerequisites
A seventh, calendar synchronisation, is covered in its own section below because its failure mode is a double booking rather than a cost.
Readiness is not a feeling about whether you are technical enough. It is six concrete questions, each of which has an answer today.
| Prerequisite | The question | Ready when |
|---|---|---|
| Payments | Who processes cards, and who bears a chargeback. | You can name the processor and the terms. |
| Agreement | What terms bind a direct guest. | The terms exist, in writing, and you have read them. |
| Insurance | What cover applies to a direct booking. | You have asked your insurer, not assumed. |
| Support | Who answers a guest with a problem. | A named process that does not depend on you being awake. |
| Compliance | What your licence and local rules require. | Checked against the authority, not against a platform. |
| Demand source. | Who will actually book here. | You can describe them without using the word everyone. |
Six answers. All available today.
The one that fails most often
Demand source. It is the only prerequisite that cannot be bought, configured or subscribed to, and it is the one hosts skip because the other five feel more like real work.
Insurance is the Quiet One
Payments and agreements get attention because they are visible in the booking flow. Insurance does not appear anywhere in the flow and is the one most likely to be discovered after an incident.
Ask your insurer before you take a direct booking.
A booking taken outside a platform may sit under different terms from one taken on it. Whether it does is a question for your insurer about your policy, and it is a short conversation to have in advance.
Three Outcomes, Each with a Date
The gate resolves to one of three, and each carries a date. A decision without a date is a preference.
Build
You build when all six prerequisites are ready and you can name the demand source. Set the date you will look at whether direct bookings actually arrived.
Close prerequisites first
You close first when the demand source is real but one or more of the other five is not. Name each gap, name who closes it and name when. Then revisit.
Defer
You defer when the demand source is not there yet. That is the honest answer far more often than hosts expect, and deferring costs nothing beyond a note in the calendar.
Defer is cheap. A dead site is not.
Record the gate in four lines
- The date you ran the gate.
- The six prerequisite scores, as ready, partial or absent.
- The demand source, described in one specific sentence.
- The decision and the date you will revisit it.
Four Ways a Direct Site Becomes an Expense
Direct booking projects rarely fail loudly. They fail by sitting there, and there are four common routes to that outcome.
Building before naming a demand source
The site goes live, the payment flow works, the design is fine and nobody comes. Every part of the project succeeded except the one that was never specified.
A working site with no visitors is still a cost.
Treating it as a one time build
A site needs updating, its engine needs maintaining and its terms need reviewing. The reported low cost per booking assumes a working site, and working is a state you maintain rather than reach once.
Built once. Maintained always.
Running it alongside platforms without syncing
A direct booking and a platform booking can take the same night. If the calendars do not talk to each other, the first serious week of direct demand produces a double booking.
Two channels. One calendar. Always.
Skipping the insurance question
It costs one phone call in advance and it is the item most likely to matter exactly once, at the worst possible moment.
One call now. Or one problem later.
What This Gate Cannot Tell you
The limits matter here because direct booking attracts confident claims, and nothing on this page supports any of them.
- It cannot tell you a direct site will bring bookings.
- It cannot tell you what your own cost per booking would be.
- It cannot compare platforms, which was not measured.
- It cannot tell you what other hosts achieved, which is not evidence about you.
- It cannot tell you whether building is worth it, only whether you are ready.
Readiness is the question here. Nothing else.
Cancellation behaviour is sometimes offered as a further argument. Hospitality Net reports that cancellations through online travel agencies can approach 50% in some markets, against around 18 to 20% for direct bookings. That is a reported pattern for hotels, not a prediction for your property.
Where This Sits Among your Other Decisions
A direct site is often considered for a reason that has nothing to do with distribution, and the gate works better when the real reason is on the table.
If the reason is a quiet calendar, run the booking layer audit first, because building a site is a slow answer to a problem that may be a setting. If the reason is that another platform looks attractive, the channel readiness score is the closer comparison. And if the reason is that your economics changed, the fee calculator models both sides of that directly.
Name the real reason before you build anything.
A note on being found
A direct site has to be discoverable to be useful, and that is its own project. Airbnb, for instance, has a setting that controls whether search engines display your listing pages, which is a reminder that discoverability is always a setting somewhere.
Your own site has no such switch to flip. Being found is work you take on when you build, and it belongs in the demand source prerequisite rather than being assumed to follow.
Pass the gate. Then decide. Then build.
In that order.
Not before.
And not on a hope.
A site is easy to start and slow to stop.
So start it with a reason you can name.
Then the rest is just work.
Work you chose, with a date on it.
That is what ready looks like.
Anything else is a project you drift into.
And drifting is what makes it expensive.
So run the gate first. It takes an hour.
An hour now. Or a year of a site nobody visits.
Take the hour.
What to look at six months after you build
If you do build, the review is short and it has one question. Did the demand source you named actually send bookings to the site? Not whether bookings exist, which they may for other reasons, but whether the specific source you predicted delivered.
You named a source. Check that source.
A yes means the model works and you can invest further with a reason. A no means the site is running on demand you did not plan for, which is worth understanding before you assume it continues.
Either answer is useful. What is not useful is looking at total direct bookings and calling it a result, because that number moves for reasons that have nothing to do with the decision you made when you built.
Check the prediction. Not the total.
If you defer instead
Deferring is not doing nothing. Put a date on it and name the one condition that would change the answer, which is almost always the demand source. Then work on that condition rather than on the site.
Repeat guests, a referral habit and a reason for people to look you up are all things you can build without a website. If they arrive, the gate passes on its own and the build becomes obvious rather than debatable.
Build the demand. The site follows.
That order is slower to start and much harder to regret. A site built for demand that already exists starts working immediately. A site built to create demand starts a second project you had not planned for.
Demand first. Infrastructure second.
Questions Hosts Ask About This Decision
Is a direct site really cheaper per booking?
Hospitality Net reports around 4% to 5% once a working website and booking engine are in place, against 15% to 30% of booking value through online travel agencies. The condition on the first figure is the whole point.
Will a direct site bring me more bookings?
Nothing here supports that. A site changes who you pay when a booking arrives. Where the booking comes from is the demand source prerequisite, and it is the one that fails most often.
Who books directly?
Typically guests who already know you exist: repeat guests, referrals and people who found you elsewhere. If you cannot describe yours specifically, the honest score on that prerequisite is absent.
What about insurance?
Ask your insurer whether a booking taken outside a platform sits under the same terms. No general guide can answer it, and it is a short conversation to have before the first direct booking rather than after an incident.
Do cancellations differ?
Hospitality Net reports that cancellations through online travel agencies can approach 50% in some markets against around 18 to 20% for direct bookings. It is a reported pattern for hotels, not a forecast for you.
What if I score partial on most prerequisites?
Then close them first, or defer. Partial is a normal starting point. Partial and already building is how a site ends up live with a payment flow nobody has tested.
Operator Notes
Three notes below are reserved for Sean and are deliberately unfilled. Nothing has been written into them on his behalf, and no view below is attributed to him.
- The prerequisites Sean requires before building direct: ______________________________.
- How Sean describes a real demand source: ______________________________.
- When Sean defers a direct site rather than closing gaps: ______________________________.
Sources and what each one does not prove
- Hospitality Net. Distribution cost comparison between OTA and direct channels for independent lodging. What it does not establish: Written about independent hotels, not short-term rental hosts. Ranges are the author's, the sample is not stated, and none of it transfers to one listing without checking that listing's own terms. Checked 2026-07-28.
- Hospitality Net. US hotel occupancy, ADR and RevPAR for the week ending 18 July 2026, by market. What it does not establish: Hotel performance, not short-term rental performance. A market average is not one property's pickup and carries no forecast for any future week. Checked 2026-07-28.
- Airbnb Help Center. The host-controlled setting that includes or excludes a listing from search engines. What it does not establish: An eligibility switch, not an indexation guarantee. Turning it on does not prove any search engine has indexed the page. Checked 2026-07-28.
- Airbnb Help Center. Platform-wide service fee mechanics as documented by the platform itself. What it does not establish: Documents the published structure, not what any individual account was moved to or when. Account state and country coverage vary. Checked 2026-07-28.
The Seventh Prerequisite: Calendar Synchronisation
The six prerequisites above are about whether you can run the channel. This one is about whether running it can hurt you, and it deserves its own gate because the failure mode is a double booking, which costs far more than the commission you were saving.
| Approach | How it works | Double-booking risk | Fits |
|---|---|---|---|
| Manual | You update both calendars yourself | High. Depends entirely on you never being asleep, busy, or on a plane. | Nobody, really. Occasionally a very low-volume single listing. |
| iCal sync | Calendars exchange availability files on a polling interval | Moderate. The polling interval is a window in which both channels believe a night is free. | Single listings with low simultaneous demand |
| Channel manager | One system holds availability and pushes to every channel | Low | Multiple listings, or any listing with real direct volume |
| Full PMS | Channel management plus operations, messaging, and reporting | Low | Portfolios where operations, not just calendars, need one system |
THE iCAL GAP IS REAL AND IS NOT A BUG
iCal synchronisation is not instantaneous. Calendars poll on an interval, so there is always a window between a booking landing on one channel and the other channel learning about it. Two guests can book the same night inside that window. It is inherent to the mechanism.
Decide in advance which channel wins a collision and what you will do for the guest who loses. Deciding that during the incident is how a commission saving turns into a cancellation, a refund, and a review you cannot remove.
Three Build Paths
Vendor-neutral, because the right path depends on your volume and your tolerance for maintenance rather than on which product is best.
| Path | What it is | Typical effort | Best when | Watch out for |
|---|---|---|---|---|
| Widget on an existing site | A hosted booking widget embedded in a page you already have | Lowest | You already have a site with traffic, and want to test direct demand cheaply | Limited control over the booking flow and the guest data |
| Purpose-built booking platform | A hosted product that provides site, engine, and often channel sync together | Moderate | Most hosts who pass the gate. One vendor, one bill, one support line. | Recurring cost, and portability of your content and guest data if you leave |
| Custom build | Your own site with an engine and payment integration | Highest | Portfolios with requirements no product meets | You now own the maintenance, the security patching, and the PCI scope questions permanently |
ON PAYMENT SCOPE
The main practical reason to prefer a hosted engine over a custom build is that a hosted engine keeps card data out of your systems, which keeps your compliance obligations narrow. A custom build that touches card data expands them substantially. If you do not know what your obligations would be, that is itself a strong signal to choose a hosted path, and a question for your processor before you build anything.
Build, Defer, or Do Not Build
| Condition | Decision | Next action |
|---|---|---|
| Any of the seven prerequisites is unanswered | Do not build yet | Answer it. None of them takes more than a phone call and an afternoon. |
| You cannot name a demand source without saying "everyone" | Do not build | Build the audience first. The engine converts demand; it does not create it. |
| Your break-even booking count exceeds a realistic share of your annual bookings | Defer | Set a volume trigger and a review date. Revisit when volume changes, not when you feel like it. |
| Insurance position on direct bookings is unknown | Do not build | Ask your insurer. This is the cheapest question on the page and the most expensive to skip. |
| You cannot commit to a synchronisation method you trust | Do not build | Solve sync first. A double booking costs more than a year of commission. |
| All seven pass, break-even is reachable, and you have repeat guests already asking to book direct | Build | Start with the 90-day pilot below, not a full build |
| All seven pass but you have no repeat guests yet | Defer | Revisit after a season of operating. Repeat guests are the cheapest direct demand there is. |
The 90-Day Bounded Pilot
If you land on build, do not build the full thing first. A pilot answers the one question the arithmetic cannot: whether your demand source is real. It is designed to be cheap to abandon.
Days 1–7: instrument before you build. Write down your current bookings per month, your average booking value, your repeat-guest count over the last twelve months, and your platform fee rate. Without a baseline the pilot cannot produce a verdict.
Days 8–21: build the smallest possible version. A single page and a hosted booking widget. No blog, no multi-property architecture, no custom design. You are testing demand, not craftsmanship.
Days 22–30: close the seven prerequisites in writing. Processor terms, guest agreement, insurer confirmation, support process, compliance check, named demand source, and sync method. In writing means you can produce the document, not that you remember the conversation.
Days 31–90: drive your named demand source and nothing else. Past guests, your existing audience, referrals. If your named source cannot produce traffic in 60 days, you have learned the most valuable thing this pilot can teach you, at a fraction of the cost of a full build.
Day 90: judge it against the baseline, and be willing to stop. A pilot you were never willing to abandon was not a pilot.
| Measure | Baseline (day 1) | Day 90 | Verdict |
|---|---|---|---|
| Direct bookings taken | 0 | ______ | Zero after driving a named source is a clear stop |
| Direct nights | 0 | ______ | Compare against your break-even night count |
| Total bookings across all channels | ______ | ______ | If total is flat, you moved bookings rather than adding them |
| Fees saved on direct bookings | $0 | $______ | Compare against pilot cost including your hours |
| Hours you spent | 0 | ______ | The line people forget. Value it honestly. |
| Double bookings or sync incidents | 0 | ______ | Any incident means fix sync before scaling |
THE RESULT THAT LOOKS LIKE SUCCESS AND IS NOT
Direct bookings arrive, and your total bookings across all channels stay flat. You have not gained bookings. You have moved existing bookings to a cheaper channel, which is a genuine saving, and you should measure it as a saving rather than as growth.
The distinction matters because the two justify very different amounts of further investment. A channel that shifts existing demand is worth its running cost. A channel that adds demand is worth building on.
Vendor-Neutral Implementation Checklist
If you build, these are done before you take the first direct booking. No exceptions, and the order is deliberate.
| Item | Done when |
|---|---|
| Payment processor selected, terms read | You can state who bears a chargeback and under what conditions |
| Guest terms and conditions published | They exist in writing, you have read them, and they are linked in the booking flow |
| Cancellation and refund policy published | It is stated before booking, not after |
| Insurer confirmation on direct bookings | You have it in writing from your insurer, not an assumption |
| Local compliance and licensing verified | Checked against the issuing authority, not against a platform's requirements |
| Tax collection and remittance handled | You know who collects and remits, because a platform may have been doing it for you |
| Calendar sync live and tested | You have tested it with a real booking and watched the other channel update |
| Collision rule decided | You have written down which channel wins and what the losing guest is offered |
| Support path defined | A guest with a 2am problem reaches someone, and it is written down |
| Booking confirmation and pre-arrival messages written | The platform was sending these for you. Now you are. |
| Privacy notice covering guest data | Published, and accurate about what you collect |
| Test booking completed end to end | You booked your own property with a real card and refunded it |
THE LAST ROW IS NOT OPTIONAL
Book your own property with a real card, take the payment, read every automated message the guest receives, then refund it. A surprising number of direct channels go live with a broken confirmation email or a payment flow that fails on mobile, and the first person to discover it should not be a paying guest.
The guide above was assembled from the primary sources listed and checked on the dates shown. It organises an operating decision and does not provide legal, tax, accounting or insurance advice. Account specific and local facts may control the answer for your property.