A holiday rental website doesn't have to
websitesholiday-rentalscustom-softwareastro
A holiday rental website can do more than display a few photos and an email address. But that does not mean it needs to accept bookings automatically.
For Capricorn Dancer, an architectural beach house in Woorim on Bribie Island, the owner wanted to keep a personal booking process. She preferred to receive an enquiry, speak with the guest and confirm the stay herself.
That was not a problem to automate away. It was the starting point for the website.
Automate the preparation, not the decision
Before a guest sends an enquiry, they usually want to answer a few practical questions:
- Does the house suit our group?
- What is nearby, and what can we do during our stay?
- Are our dates available?
- Is there a minimum stay during that period?
- Roughly what will it cost?
A brochure site leaves most of those questions for the host to answer. An instant-booking platform answers them, but also makes a commitment on the owner’s behalf.
We built the space in between: property and local information, an availability calendar, booking-rule guidance and an estimated price, followed by a direct enquiry. The supporting work happens automatically. Accepting the booking does not.
Availability needs to account for the booking rules
An open night is not always a bookable stay.
A property might have a standard minimum stay and a longer minimum during a holiday period. A short gap between two existing bookings might look available even though no eligible stay can fit into it.
Capricorn Dancer’s calendar combines imported held dates with the owner’s minimum-stay rules. Guests can see the applicable requirements, and gaps too short for a valid stay are marked unavailable. The enquiry backend checks the rules again when the request is submitted.
The owner can update the default minimum and add date-specific rules through the CMS. Those rules belong in editable settings, not in a developer’s inbox every time a holiday period changes.
There is an important limit: the external calendar feed refreshes periodically. It is not a real-time booking lock or a two-way channel manager. The host still checks availability before accepting a stay and blocks confirmed direct bookings in the source calendar.
That limitation is another reason to call the submission an enquiry, not a reservation.
An estimate should reflect the dates, not just a “from” price
One headline nightly rate rarely explains the cost of a holiday stay. Weekends can differ from weekdays. School holidays can differ from quieter periods. Particular dates may need their own prices.
The pricing settings for this project support:
- A base nightly rate
- Weekend adjustments
- Seasonal pricing rules
- Custom prices for specific dates
- Weekly or other long-stay discounts
- A direct-booking discount
- A fixed cleaning fee
The owner manages those rules in a pricing editor, with a calendar preview showing which rule applies to each night. Base rates, weekend adjustments and seasonal periods can be changed without editing code.
Guests choose dates and see an averaged nightly rate, applicable discounts and an estimated total. Individual nightly prices do not clutter the guest-facing calendar.
The host needs a different level of detail. Her enquiry email includes the guest’s summary and an owner-only calculation showing each night’s rate, the discounts and the cleaning fee.
The same stay therefore has two useful views: a clear estimate for the guest and a checkable calculation for the person responding.
The server recalculates that estimate from the saved rules before sending the emails. It does not trust a price supplied by the browser.
Direct enquiries create room to offer savings
Booking marketplaces can help guests discover a property. A direct website gives the owner another way to receive enquiries, with control over the information and pricing presented there.
For Capricorn Dancer, a configurable direct-booking discount makes that benefit visible in the estimate. An eligible longer stay can also receive a long-stay discount.
The point is not to promise that direct is always cheapest. Rates, fees and promotions differ between channels. The useful capability is that the owner can choose to pass on savings from avoiding marketplace booking charges, rather than having every guest enquiry lead back through the same platform.
This website supports that choice. It does not claim to replace the audience or discovery a marketplace provides.
Keep the human handoff clear
After a successful enquiry, both parties receive an email.
The guest gets their request details and estimated price, with explicit wording that the enquiry is not a confirmed booking and the dates have not been reserved.
The host gets the information needed to review the stay and reply, including the detailed price breakdown. She can continue the conversation personally and agree the final price.
No payment is taken on the website. Submitting the form does not block dates. Enquiries are recorded in the emails rather than a separate booking database.
Those boundaries are deliberate. They keep the system aligned with the owner’s process and avoid giving guests the impression that an automated reservation has occurred.
An editable website can still be mostly static
The public pages are built with Astro and served through Cloudflare Pages. Small Pages Functions handle the dynamic work: retrieving availability and processing enquiries.
Keystatic runs separately on a Cloudflare Worker. The owner uses it to update content, images, property details, activities, pricing and minimum-stay settings.
The publishing flow is straightforward:
- The owner saves an edit in Keystatic.
- Keystatic records the change as a GitHub commit.
- The commit triggers a Cloudflare Pages build.
- The updated static site goes live when the build succeeds.
The result is an editing workflow for the owner without making every visitor’s page request depend on the CMS. Content changes are also recorded in version history.
The project is built for fast loading, and its current Cloudflare deployment is reported to run within the free tiers. That does not mean every running cost disappears: domains, email services, maintenance and usage beyond provider allowances still need consideration.
Nor does a static site mean everything must be static. It means the pages are pre-built, while the small parts that need fresh information use an API.
When this approach fits — and when it doesn’t
An enquiry-first website is a useful fit when the owner wants to review stays personally but guests still need good information before making contact.
It is less suitable when the business needs instant confirmation, online payments, live inventory across several channels or a full property-management system. Those requirements call for a different scope, often including an established booking engine or channel manager.
The lesson from Capricorn Dancer is not that booking automation is bad. It is that the website should support the process the owner actually wants.
In this case, that meant making dates, rules, estimates and email handoffs easier — and leaving the booking decision with the host.
Explore the Capricorn Dancer project for the delivered scope, or try our direct booking website demo to find out whether this approach fits your property.
Have a holiday rental that needs better direct enquiries, rather than an automated checkout? Tell us how you manage bookings, and we can work out which parts of the process your website should handle.