8 min read

Building a reservation engine without a SaaS

Why we built the calendar, the availability logic, and the deposit flow from scratch.

The first question on every platform build is the same: do we reach for a SaaS booking engine, or do we build our own? For a property with a real guest relationship to protect, the answer is almost always to build.

Here is why.

The SaaS problem

Booking SaaS providers—Lodgify, Hostfully, Guesty, and their cousins—are built for scale. They are optimised for a host managing twelve properties across four platforms, where the goal is workflow efficiency, not guest experience quality.

For a property with real character and repeat guests, the booking flow is not a workflow problem. It is a brand touchpoint. Every field, every confirmation email, every deposit request is a signal to the guest about what they’re booking into. A generic SaaS widget embeds a different brand’s assumptions into that moment.

Beyond aesthetics: most SaaS providers retain some portion of the relationship. They hold the availability data, the pricing rules, or the guest communication history behind their own API. The owner never fully owns the stack.

What we built instead

For Solaire, we built a reservation engine in three parts: availability state, the booking flow, and deposit handling.

Availability state lives in Sanity as a structured document. Blocked dates, minimum stays, pricing overrides by season—all managed through a clean owner dashboard with no technical knowledge required. iCal export syncs the calendar to any platform the property still lists on.

The booking flow is a four-step sequence: date selection, guest details, deposit review, confirmation. Each step is a server component with no third-party scripts. The confirmation email is sent via Resend with a template that matches the platform’s design language exactly—same typeface, same palette, same voice.

Deposit handling is Stripe Payment Intents with a configurable deposit percentage. The owner sets the deposit amount in the dashboard. Stripe handles PCI compliance. Funds go directly to the owner’s connected account. There is no intermediary holding the money.

The iCal sync detail

Most owners don’t abandon their platform listings on day one of launching a direct channel. The direct channel is built in parallel—it captures returning guests and direct inquiries while the platform listings continue to generate discovery traffic.

This creates a double-booking risk if availability is not synchronized. We solve it with iCal: Solaire exports a live feed that Airbnb, VRBO, and any other platform can subscribe to. When a guest books directly, the dates block automatically across all platforms within the sync interval (typically 15–60 minutes, depending on the platform).

It is not real-time, but it is sufficient for most owner-operated properties—genuine simultaneous double-bookings in a 15-minute window are rare outside high-volume, high-turnover operations.

What the owner actually experiences

The dashboard is a single page: a calendar with booking state, an inquiry list, and a guest history table. No vendor onboarding. No seats. No per-booking fees to a SaaS provider.

When a new booking arrives, the owner gets an email. When a guest checks out, a post-stay email goes out automatically—a thank-you, a direct booking link for next season, and a soft request for a review. The email is written in the property’s voice, not Airbnb’s.

The build cost is higher up front than plugging into a SaaS booking engine. There’s no per-booking fee and no monthly SaaS subscription running in the background—just a light maintenance fee to keep the platform itself running. The brand fidelity is complete. That calculus holds regardless of property size.

Working on a direct channel? Let’s talk.

Book a discovery call →