What it solves
Planning a multi-day backpacking trip means turning a route into a schedule: how many days it actually takes given the elevation and your own effort budget, and where along it you are legally allowed to sleep. GPX files give you a line on a map, not a plan. trailplan takes that line, re-derives its elevation, splits it into days that respect a physical effort budget, and attaches a real, permitted overnight location to each split.
How it is built
A FastAPI backend owns all the domain logic — route ingestion, elevation, day-splitting, effort scoring — and a React client with a MapLibre GL map is a thin layer on top of it. Postgres on Neon holds routes and plans, and the whole thing runs on Cloud Run.
Two hard decisions
The first is unit handling: everything internal is SI, and imperial only appears at the very edge, converted in exactly one place — the plan bundle builder. Elevation, distance and effort scoring all interact, and letting imperial creep in anywhere upstream of that one conversion point is how you get unit drift: a bug that does not crash anything, just quietly returns a number that is merely plausible, and that you find six months later.
The second is what is allowed to become an overnight anchor. Nothing sourced from OpenStreetMap becomes a suggested campsite without a human curation pass. The Overpass query that pulls candidates is deliberately over-broad, and then narrowed by hand, because a campsite that turns out to be illegal to sleep at is a worse failure than a campsite a human had to sit down and approve.
What it taught me
The unit-conversion bug you don't get is more valuable than the one you catch, and the way to get there is to make the wrong thing hard to write rather than trust yourself to catch it in review. The same logic applies to the campsite data: automating the easy 90% of curation and forcing a human decision on the rest is a better shape than either fully automating it or fully hand-curating it.