Live Evidence level: Verified result

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

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

Part of Alaska Backcountry Access
Client
Alaska ATV Rentals (AlaskaATVRentals.com)
Sector
Vehicle rental — Alaska
Role
Built and maintained by me — architecture, build, and booking-data model
Period
2026 · live
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

Alaska ATV Rentals lets 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 was 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, the rules for what customers never see — and ongoing maintenance now that it is live.

  • Xola remains the booking and payment backend — the site routes to it, it does 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 lives 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

Direct checkout routes across the fleet

Pickup vehicles across one-to-five-day durations map to 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 (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.

  • The live site

    Alaska ATV Rentals is live in production: a static Astro booking router that sends each rental choice to the correct Xola checkout. Named with the client's written permission (June 2026).

    Visit AlaskaATVRentals.com

    Public production website · verified June 2026

  • Sanitized booking-route matrix

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

    Direct-booking matrix
    Vehicle classes × durations = direct 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 2026

Evidence

What backs this up

  • Live website

    Verified

    AlaskaATVRentals.com is publicly reachable, serving the static Astro build with the fleet grid, duration selectors, and direct Xola checkout routing.

  • 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 — version-controlled.

  • Routing rules record

    Verified

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

  • Ongoing maintenance

    Project record

    Fleet availability, pricing, and checkout links are kept current in the single data file as the operator's season changes.

Results & current state

What's true today

  • The booking decision layer is live, built around one editable data file.

    AlaskaATVRentals.com serves the static Astro site in production; routing logic, fleet data, and checkout mapping are live and version-controlled.

  • 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.

  • The fleet stays accurate without layout edits.

    Availability and pricing live in a single data file; an out-of-service vehicle is flagged once and disappears from every customer-facing choice.

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.