Wayfinder
Case study · Personal Projects
A single-page road-trip planner that holds weather, fuel, road clearance, campsites, and backups in one living itinerary, with a builder that generates the same itinerary for any traveler.
1. Summary
Wayfinder is a single-page road-trip planner that holds weather, fuel, road clearance, campsites, and backups in one living itinerary, paired with a builder that generates that same day-by-day format for any traveler. It is a personal prototype. the planner is built and has been used on a real trip, and the builder is live as a static page. There is no backend, no account, and no user data of any kind.
2. Goal
Replace the pile of half-remembered logistics with one calm source of truth that survives contact with the road. Planning a multi-state trip means holding the route in your head, the reservations in your email, the fuel estimate on a napkin, and the sights in a phone note, and by day three nothing matches anything and the one document you made went stale the moment the first campsite was booked. The design premise is a cognitive-load one: a traveler standing at a trailhead, tired and off-signal, should not have to reconstruct the plan from four apps, so everything they need at that moment lives in one document that reads the same at the desk, on the road, and a year later as a trip record.
Three rules follow from that goal and drive most of the decisions below.
- The itinerary is a document, not a chat log. It stays correct after a cancellation or a route change, and it is edited in place.
- Everything a traveler needs at a given moment lives inside the day it belongs to. Nobody should scroll to a reservations section at the bottom of the page to find a confirmation number.
- The tool links out rather than replaces. Recreation.gov still takes the booking, AllTrails still shows the trail, Mountain Project still shows the route. Wayfinder is the connective tissue.
3. Users and context
Me first: I plan multi-state van trips for a family and need one page that is the source of truth, still correct after a change, and readable in a parking lot with no signal. Then the other travelers in the van, who open it on a phone and want directions from where they are standing, tonight’s fire rule, and whether the dog can come. The builder widens that to road-trippers who want a real plan without living in a spreadsheet, some wanting a full route, some just one campground for three nights, and to friends who ask how these trips get planned and want a version safe to share. Being a personal build is the point, not a limitation: the vehicle is a tall Sprinter van, the routes cross federal, state, and BLM land with three booking platforms, and long stretches have no cell service, so any feature that needs a live connection at the moment of use is a feature that fails on the Loneliest Road.
4. How it works
Wayfinder is one product with two capabilities that share the same data model (days, stops, overnights, activities, constraints) and the same rules about what belongs on a day card. The planner is the format; the builder produces the format. One real trip is planned end to end as the working example: a 15-day van loop from Golden, Colorado out to Yosemite and home through the Eastern Sierra, southern Nevada, Zion, Bryce, Capitol Reef, and Moab, about 3,000 miles across five states and six national parks, built before the trip, used during it, and rewritten afterward to the route actually driven, which is the real test of a living document.
The planner
A single static HTML page holding one trip, organized around day cards. Each element below exists because the trip taught it.
| Element | What it does, and why |
|---|---|
| Route map | A hand-drawn SVG state-outline map with numbered stops at true position and a ranger-badge marker on each national park. No tile server and no map token, so it renders with no connection. Clicking a marker scrolls to that day. |
| Color rule | Where you sleep that night sets the day’s color, shared by the map marker, the day-jump dot, and the itinerary’s left bar, so a reader can trace any dot back to its day by color alone. |
| Overnight card | One card per night: site name and map link, then a logistics list with fire and burn-ban status first (linked to the agency that actually sets the rule for that jurisdiction), then water, showers, cell and sky view, bear storage, and dog rules. Booking confirmation and backups fold into a collapsible drawer. |
| Weather chip | Live high and low from Open·Meteo, fetched in the browser with no key. Inside the 16-day window it shows a forecast; outside it, a five-year historical average styled to make clear it is climatology, not a forecast. If both fail, a neutral placeholder rather than something wrong. |
| Fuel and clearance | Callouts on the long legs name the fuel deserts ahead and the towns to top off in, and a one-line clearance verdict appears where it matters (the Zion to Mount Carmel tunnel states the restriction, the van’s dimensions, and the verdict in advance, since there is no good way to check mid-drive). |
| Backups and direction pills | Alternate campgrounds live in the day they belong to, so a plan that falls through mid-trip is one tap from its backup. Every stop carries a map pill that opens turn-by-turn directions from the traveler’s current location, because a pin is useful at home and useless on the road. |
| Reference and record | Collapsed-by-default geology cards for the curious reader, a packing tab with per-traveler checklists that persist in the browser, and a trip budget built on fuel prices actually paid, broken out by state so the assumptions can be checked. |
| Cancellation watcher | A companion scheduled task that checks target campgrounds each morning, when the booking platforms release the sites people have cancelled. The moment a watched site opens, it pushes a calendar notification that links straight to the exact booking page, with the campground and site already identified, so the only step left is entering a card. That is the whole point: it closes the gap between a site being released and the traveler getting to the booking screen, the gap where a shoreline site is gone in minutes. It caught a Tahoe shoreline cancellation three days before departure and upgraded the leg. |
The builder
A static form that turns a traveler’s constraints into the same day-by-day structure, with two front doors because two different people show up: the one who wants a campground in an area for three nights, and the one who wants a whole route planned around a reservation they already hold. The form collects the trip frame, three pace controls (daily drive cap, days before a rest day, total rest days), a public-lands lean, repeatable reservation and destination rows, and activity checkboxes. Browser logic lays out the rhythm from the traveler’s own rules, pinning reservation nights to their dates, inserting rest days on cadence, and distributing prioritized destinations across the explore days. For every box checked it builds a targeted search link (Recreation.gov, Mountain Project, RoadsideAmerica, plus fire-restriction and road-condition searches), and it outputs a printable plan plus an optional one-click prompt.
The split is deliberate, and the tool says out loud which half is which. The page does the structured scaffolding, the pure logic: ordering days, honoring reservations, respecting the drive cap, building the right searches. The open-ended reasoning, exact routing, real drive times, and picking a specific campground, is what a language model is good at, and that happens either in the traveler’s head with the links provided or by pasting the generated prompt into their own AI tool.
5. Data, privacy, and governance
Wayfinder collects nothing. There is no account, no login, no form posted anywhere, no analytics, and no stored user data. Both the planner and the builder run entirely in the visitor’s browser. This is the same no·PII, minimum-data principle that governs my other tools, and here it is easy to hold because there is no server to hold anything. Trip content is written into the HTML file itself, packing-list check state lives in localStorage, builder form entries are discarded on close, and the only outbound call is a keyless weather lookup that sends coordinates and dates, no identity.
Because a trip page is meant to be handed to a friend, it is written to be safe to hand to a stranger: travelers appear as roles (“Mom,” “Teen”), not names, and confirmation numbers, flight details, and any reference to who will be alone and where stay out of any shared version.
6. Build and portability
The planner is a single self-contained HTML page and the builder is a second static page; both run entirely in the browser with no backend, no framework, and no build step, and host anywhere that serves static files. The route map is inline SVG with no tile server or map token, so it draws with no connection. Weather is a keyless Open·Meteo call. Packing-list state persists in localStorage; builder entries are held only in memory and discarded on close. The one piece that runs outside the page is the cancellation watcher, a companion scheduled task that checks target campgrounds each morning and pushes openings to a calendar notification. Because a static page on public hosting cannot safely hold an API key, the builder generates a prompt for the traveler to paste into their own AI tool rather than calling a model itself. That is a constraint the design leans into rather than pretends away, and it is what keeps the whole thing portable and keyless.
7. Pilot and testing
Road-tested end to end on one real trip: the 15-day, roughly 3,000-mile van loop was built before departure, used during it, and rewritten afterward to the route actually driven, which is the real test of a living document. The planner shipped as a long series of small versions across May and June 2026, each a fix for something that failed on the road: the tunnel-clearance panic, the dead trail links, the backups that were useless at the bottom of the page, the fire rules that differ by land manager. It is now handed to a few travelers to see whether someone who did not build it can reach a plan they trust without help. Nothing is instrumented, because instrumenting it would mean collecting data, and that trade is not worth making for a personal tool; feedback is qualitative and comes from asking.
8. Definition of success
The planner succeeds when the itinerary stays correct after a cancellation or a route change, when everything a traveler needs at a given moment is already inside that day, and when the whole page is usable in a parking lot with no signal. The builder succeeds when a first-time user’s own constraints produce a coherent day-by-day plan they would actually drive, and when a traveler who did not build the tool can reach a plan they trust without help. Because the tool is uninstrumented by design, success is judged by whether it holds up on a real trip and whether handed-off travelers come back with a plan, not by metrics.
9. Rollout
Today the static version delivers value with no server and no data. Turning it into a product for strangers would take real work not yet done, in roughly this order: validate every external link before publish and prefer stable hub pages over deep links, since link rot is the most likely way a generated trip fails a traveler; build a curated place database so the builder can name specific stops instead of handing over a search; and add live availability data, which would need a scheduled service rather than a static page. Saved trips, sharing, and an in-app AI call would each require a server, a database, and a key held somewhere safe, which means becoming the custodian of other people’s data. That is a deliberate line, not a default, and it stays uncrossed for now.
10. Open questions and risks
- Link rot. A dead trail, booking, or agency link fails the traveler exactly when they are relying on it. Mitigated by validating links before publish and preferring stable hub pages, but it is the standing risk.
- External-platform dependence. Recreation.gov, AllTrails, and Mountain Project own the destinations the tool links to; their changes ripple in.
- Handoff validation. Whether a traveler who did not build it can reach a trusted plan from the builder alone is still an open question, and the reason it is in a few hands now.
- The productization tradeoff. Every step toward saved, shared, or live-data trips trades the current zero-data simplicity for server, database, and key custody.
11. Roadmap
Near term: an external-link validation pass and a shift to stable hub pages over deep links. Next: a curated place database so the builder names specific stops rather than handing over a search. Later, and only if the data-custody tradeoff is worth it: optional live availability through a scheduled service, and saved or shared trips behind a minimal backend. The static, keyless, no-data version stays the default the whole way.