Wayfinder

Personal Projects · Case study

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 finished personal build. The planner has been used on a real trip, and the builder is live as a static page.

2. Goal

Replace the pile of half-remembered logistics with one calm source of truth that survives contact with the road. 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. Requirements R1 to R11 below each exist because the trip taught it.

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. Requirements R12 to R14 below cover it.

Requirements and acceptance criteria

Each requirement is one behavior. The checks beside it are what a builder or tester confirms before that requirement is called done. Status reflects what this document records as built.

#	Area	Requirement	Done when	Status
R1	The planner	The planner must draw the route map as inline SVG, a hand-drawn state outline with numbered stops at true position and a ranger-badge marker on each national park, with no tile server and no map token, so it renders with no connection.	With the network disabled, the map renders with every numbered stop and every national park marker visible. Loading the page makes no request to a map tile server and the source contains no map token. Clicking any map marker scrolls the page to the day card for that stop.	Built
R2	The planner	The planner must give each day one color, set by where the traveler sleeps that night, and use it on the map marker, the day-jump dot and the left bar of the itinerary, so a reader can trace any dot back to its day by color alone.	For every day, the map marker, the day-jump dot and the left bar of the day card show the same color. Two days with the same overnight location share a color, and changing the overnight location of a day changes all three elements together.	Built
R3	The planner	The planner must show one overnight card per night with the site name, a map link and a logistics list that puts fire and burn-ban status first.	Every night of the trip has exactly one overnight card inside its own day. The logistics list reads in this order: fire and burn-ban status, water, showers, cell and sky view, bear storage, dog rules. The fire and burn-ban entry links to the agency that sets the rule for that jurisdiction. The booking confirmation sits in a drawer that is collapsed on load and opens on one tap.	Built
R4	The planner	The planner must list alternate campgrounds inside the day they belong to, so a plan that falls through mid-trip is one tap from its backup.	Each day that has backups shows them in that day’s drawer and not in a separate section of the page. From any overnight card, the backups for that night are reachable in one tap without scrolling to another day.	Built
R5	The planner	The planner must give every stop 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.	Every stop on every day card carries a map pill. Tapping a pill on a phone opens directions whose destination is that stop and whose origin is the current location of the device, not a fixed start point.	Built
R6	The planner	The planner must show a weather chip with the high and low for each day, fetched in the browser from Open-Meteo with no key. A historical average is styled to make clear it is climatology, not a forecast, and a failed lookup shows a neutral placeholder rather than something wrong.	For a date inside the 16-day window, the chip shows a forecast high and low. For a date outside the 16-day window, the chip shows a five-year historical average and is styled differently from a forecast. When both lookups fail, including with the network disabled, the chip shows a neutral placeholder and no temperature. The weather request carries coordinates and dates only, with no key and no identifier.	Built
R7	The planner	The planner must show fuel callouts on long legs and a clearance verdict wherever a vehicle restriction applies, stated in advance, since there is no good way to check mid-drive.	Each long leg names the fuel desert ahead and the towns to top off in. Each clearance callout states the restriction, the dimensions of the van and a one-line verdict. The Zion to Mount Carmel tunnel day shows its clearance callout on the day card for that drive.	Built
R8	The planner	The planner must show geology reference cards for the curious reader that are collapsed by default.	On first load every geology card is collapsed. Opening a geology card does not move or hide the logistics content of that day.	Built
R9	The planner	The planner must provide a packing tab with a checklist per traveler whose check state persists in the browser.	Each traveler role has its own checklist on the packing tab. A box checked before a page reload is still checked after the reload in the same browser. Check state is stored in localStorage only and is sent nowhere.	Built
R10	The planner	The planner must show a trip budget built on fuel prices actually paid, broken out by state.	The budget shows one fuel line per state crossed. Each state line shows the price used, so the assumption can be checked against a receipt. The state lines add up to the fuel total shown.	Built
R11	The planner	The cancellation watcher must check the target campgrounds each morning, when the booking platforms release the sites people have cancelled, and push a calendar notification when a watched site opens, so the only step left is entering a card. 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 task runs once each morning without anyone starting it. When a watched site becomes available, a calendar notification arrives that names the campground and the site. The link in the notification opens the booking page for that exact site. On a morning with no openings, no notification is sent.	Built
R12	The builder	The builder must lay out a day-by-day plan in the browser from the trip frame, the three pace controls, the public-lands lean, and the reservation and destination rows the traveler enters.	Every reservation night appears on the date the traveler entered for it. Rest days appear on the cadence set by the days-before-a-rest-day control and do not exceed the total rest days entered. No driving day in the plan exceeds the daily drive cap entered. The form can be completed both for a single campground stay and for a whole route built around an existing reservation.	Built
R13	The builder	The builder must output a printable plan that carries a targeted search link for every activity box the traveler checked.	Each checked box produces at least one search link in the plan, and an unchecked box produces none. The plan includes fire-restriction and road-condition search links. The plan prints from the browser print dialog with every day and every link present.	Built
R14	The builder	The builder must offer an optional one-click prompt that the traveler pastes into their own AI tool, and must not call a model itself.	One click produces the full prompt text ready to copy. The prompt contains the constraints the traveler entered. Using the builder from start to finish sends no request to any AI service. The page states which work it does itself and which is left to the traveler or their AI tool.	Built
R15	Data, privacy, and governance	Wayfinder must collect, post and store no user data beyond packing-list check state in localStorage.	A network trace of both pages shows no form post, no analytics call and no outbound call other than the weather lookup. Neither page asks for an account or a login. After the builder page is closed and reopened, every form field is empty. A version of a trip page prepared for sharing shows travelers as roles and contains no confirmation numbers and no flight details.	To verify
R16	Build and portability	Wayfinder must run as two static pages with no backend, no framework and no build step.	Both pages work when served from any plain static file host with no server-side code. The planner is one self-contained HTML file. The source of both pages contains no API key or token.	Built

5. Data, privacy, and governance

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

Both pages run entirely in the browser and host anywhere that serves static files (R16). The one piece that runs outside the page is the cancellation watcher. 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, which keeps the whole thing portable and keyless.

Dependencies

What has to be in place, and who provides it.

Needed	Provided by	Needed for
Open-Meteo forecast and historical weather data, reachable without a key	Open-Meteo	R6
Booking pages and availability on the campground booking platforms, including Recreation.gov	The booking platforms	R3, R11, R13
Trail and route pages on AllTrails and Mountain Project, and search pages on RoadsideAmerica	The external sites	R13
Fire-restriction and burn-ban pages published for each jurisdiction	The land management agency for each jurisdiction	R3, R13
A calendar that can receive pushed notifications	The traveler	R11
A place to run the scheduled task each morning, outside the static page	To be assigned	R11
An AI tool to paste the generated prompt into	The traveler	R14
Static file hosting	The owner of the product	R16

7. Pilot and testing

Road-tested end to end on one real trip: the van loop described in section 4. The planner shipped as a long series of small versions, 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 three rules in section 2 hold on a real trip and 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. Success is judged by 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 the work in the roadmap (section 11). 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 line stays uncrossed for now.

Out of scope

• Wayfinder does not take bookings; the booking platform still takes the booking and Wayfinder links to it.
• Wayfinder does not replace trail or climbing route sites; it links out to them.
• Wayfinder does not call an AI model from the page; the traveler pastes the generated prompt into their own AI tool.
• The builder does not pick a specific campground, compute exact routing or compute real drive times.
• Wayfinder does not save or share trips through a server.
• Wayfinder does not show live campsite availability inside the page.

10. Open questions and risks

• Link rot. A dead trail, booking, or agency link fails the traveler exactly when they are relying on it. Not yet mitigated; it is the first roadmap item.
• External-platform dependence. Recreation.gov, AllTrails, and Mountain Project own the destinations the tool links to; their changes ripple in.
• Handoff validation. Still an open question, and the reason the tool is in a few hands now.

Questions to settle before the next build

1. What exactly must the builder output contain: only a printable day list with search links, or the full planner format with map, overnight cards and weather chips?
2. Where does the cancellation watcher run, which booking platforms and which calendar does it use, and how does it detect an opening?
3. How is a shared version of a trip page produced, and which fields must be removed from it?
4. In the builder, how are destinations prioritized and distributed, is the drive cap in hours or miles, and what should happen when reservations, the drive cap and rest days cannot all be honored?
5. Which parts of the planner must work with no signal, and should weather be kept from the last successful fetch or always fall back to the placeholder?

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.