Pre-launch Validation Evidence level: In progress

A booking router that turns ‘which ATV, how long?’ into a checkout link

A static website that acts as the clean decision layer for an Alaskan ATV/UTV rental fleet — routing every rental choice to the right Xola checkout, and the complicated cases to a human.

Client
ATV and UTV rental operator (Alaska)
Sector
Vehicle rental — Alaska
Role
Architecture, build, and booking-data model
Period
2026 · in validation
Services
Static site architecture (Astro) · Booking-flow design · Xola checkout integration · Booking data model · Local SEO foundation
Tools
Astro · Cloudflare Pages · Xola · GitHub

The business

An ATV/UTV rental operation where customers choose between self-guided pickup rentals (one to five days, or longer custom trips) and delivered trailhead packages. Xola handles scheduling, checkout, and payments. The problem is everything before checkout: helping a visitor pick the right vehicle, duration, and option without confusion.

The real problem

Rental choices multiply fast — vehicle × duration × pickup-versus-delivered — and a generic website turns that into a maze. Long custom rentals involve trailers, deposits, and custom pricing that genuinely need a conversation. And fleet reality changes: when a vehicle is out of service, it must disappear from the customer's view entirely without anyone editing page layouts.

My responsibility

Design and build of the entire decision layer: the site architecture, the booking-data model that drives it, the routing logic into Xola checkout, and the rules for what customers never see.

  • Xola remains the booking and payment backend — the site must route to it, not duplicate it.
  • No backend of its own: a static site, so there is nothing to crash, patch, or pay monthly hosting for.
  • Booking option data must live in one file an operator can update without touching layout code.
  • Unavailable equipment must be hidden from customers while staying documented internally.

What was built

The solution, in modules

01

The booking-router model

The website is a decision layer, not a booking engine. Customers make two or three clear choices and land on exactly the right Xola checkout — the site never handles money, availability calendars, or payments.

02

Fifteen direct checkout routes

Three pickup vehicles across one-to-five-day durations map to fifteen direct Xola checkout links — each choice goes straight to the correct pre-configured checkout instead of a generic catalog.

03

A human gate for complex trips

Rentals of six days or more involve custom pricing, trailer configurations, and deposits — so that path deliberately opens a text-message conversation with the operator instead of pretending automation can scope it.

04

One source of truth for booking data

Every bookable option — price, duration, vehicle, checkout URL — lives in a single data file. Operational notes for the owner live alongside, in a field the site is designed never to render publicly.

05

Availability without layout edits

An unavailable vehicle is flagged once in the data file and disappears from the fleet grid, selectors, and pricing everywhere — while remaining documented internally for when it returns.

06

Trailhead packages

Delivered trailhead packages filter by location, date, and vehicle so only genuinely available combinations are offered.

System view

The customer's decision path

  1. 01

    Choose the experience

    Self-guided pickup rental, or a delivered trailhead package.

  2. 02

    Pick vehicle and duration

    Only available vehicles are shown; one to five days for direct booking.

    1–5 days → direct Xola checkout link (15 pre-mapped routes)

  3. 03

    Longer or custom?

    Six or more days needs trailers, deposits, and custom pricing.

    6+ days → opens a text-message conversation with the operator

  4. 04

    Checkout in Xola

    Scheduling, payment, and confirmation stay in the proven booking backend.

Conceptual flow of the routing logic — checkout and payment happen in Xola, not on the site.

Inspectable proof

Proof you can inspect

Sanitized artifacts show the underlying work without exposing client identities, credentials, private dashboards, or customer data.

  • Sanitized booking-route matrix

    The routing model is shown without checkout URLs, prices, phone numbers, or equipment identifiers.

    Direct-booking matrix
    3 vehicle classes × 5 durations = 15 mapped routes
    Standard duration
    1–5 days routes to the matching checkout
    Custom duration
    6+ days routes to a human conversation
    Availability rule
    Unavailable equipment is removed from every customer-facing choice

    Booking data model and routing rules · verified June 13, 2026

  • Pre-launch checklist

    The build exists, but the status remains validation until production data and hosting are independently confirmed.

    Built
    Static Astro decision layer and booking-data model
    Pending
    Checkout URL, price, and fleet-availability verification
    Pending
    Canonical domain, redirects, and live deployment check
    Public status
    Pre-launch Validation — not Live

    Dated launch checklist · verified June 13, 2026

Evidence

What backs this up

  • Project repository and booking-data model

    Verified

    Astro codebase with the bookingData source-of-truth file: per-option pricing, durations, checkout URLs, and the hidden-equipment flag — inspectable and version-controlled.

  • Routing rules record

    Verified

    Documented decision model: 15 direct 1–5-day checkout routes, the 6+ day SMS gate, and customer-facing hiding of unavailable equipment.

  • Production data verification

    Pending

    Every checkout URL, price, and availability value is being verified against the live Xola configuration before launch.

  • Deployment and domain checks

    Pending

    Cloudflare Pages deployment, canonical domain, and redirects are pending final confirmation.

Results & current state

What's true today

  • The full decision layer is built and modeled around one editable data file.

    Repository evidence: routing logic, fleet data, and checkout mapping exist and build; no claims about live performance are made.

  • Complex bookings route to a human by design.

    The 6+ day path intentionally opens SMS — scope decisions stay with the operator instead of a form pretending to price custom trips.

Is your booking path making customers think harder than they should?

Describe your setup in a few sentences — you'll get a plain answer about whether and how I can help.