This translates OurHikeValues.md into concrete features. v1 scope was narrowed on 2026-07-24: keep the first release small, get it in hikers' hands, then grow.
v1 targets replacing two tools: Avenza (what NYNJTC used, now shut down) and FarOut/Guthook (the ATC's current official AT map app, used by most thru-hikers). Revenue from OurHike is meant to help fund the ATC and its affiliated maintaining clubs — the nonprofits that actually build and maintain the trail — so this isn't just a free replacement, it's meant to be a better funding mechanism for them too.
Keep this simple. One thing, done well: an offline-capable map app for hikers, built on a downloadable dataset, showing the handful of things thru-hikers actually need mid-hike.
- Trail line / route data, downloadable for offline use. Design drafted 2026-07-28: see TRAIL_BLAZE_COLORS.md - the line should render in the real blaze color painted on the trail (already present as a proper coded field in ATC's own
side_trailsdata), not an arbitrary app color, with a neutral fallback where the color is genuinely unknown. - Water sources
- Trailheads & road crossings
- Shelters & campsites
- Resupply points (towns, stores, post offices)
- "You are here" GPS positioning while fully offline. Map controls (locate-me, zoom, scale, legend) detailed 2026-07-28: see MAP_OPTIONS.md - reuses MapLibre's built-in controls plus a hand-built legend, with web vs. mobile UX spec'd separately. The compass button on that same control, and dark-mode auto-detection for the outdoor usability pass below, are detailed 2026-07-28 in UX_CUSTOMIZATION.md - full auto-rotate is real Post-MVP work, flagged there as harder than it looks.
- Basic search/filter by POI type
- Same core experience on phone (iOS + Android, day one) and on the web
- Waypoint icon spec (2026-07-25, from Guthook Guides redesign case study — see "UX principles" below): ~8 color-coded POI categories, one accent color per category against a contrasting background, WCAG AA contrast compliance. A concrete, testable spec to design the shelter/water/resupply/etc. icons against, not just "make it readable."
- Elevation profile, moved into MVP 2026-07-28 (originally scoped Post-MVP under TRIP_PLANNING.md - pulled forward on its own, without the rest of that feature): a full interactive elevation profile chart plus gain/loss for any selected stretch of trail, and a time estimate via Naismith's Rule (a real, established hiking-pace formula, not a custom one). Real competitive weight (FarOut's signature feature) and a genuine safety angle - knowing a big climb is ahead affects pacing and whether to push on before dark (value #4). Accuracy is the whole point, not a detail: sourced from real bulk-downloadable USGS 1-meter DEM data (
prd-tnm.s3.amazonaws.com/StagedProducts/Elevation/1m/, the same S3 infrastructure the topo quads already come from, confirmed directly), sampled densely along the actual trail geometry rather than only at the existing half-mile markers - sparse sampling is exactly what makes other apps' gain/loss feel wrong (it misses real small ups-and-downs). Because this comes from a surveyed dataset rather than live phone GPS/barometer, it also avoids the opposite problem other apps have: sensor noise inflating apparent gain when summed over many small steps. The rest of trip planning (bulk multi-day editing, POI-aware planning assistance, the hierarchical Hike/Segment structure) stays Post-MVP as designed - this is just the elevation data and its display pulled forward on its own.
Explicitly deferred, not because they're low-value, but to keep v1 shippable:
- Community-submitted condition reports & maintainer verification
- Trail magic / hiker-to-hiker features
- Multi-club admin/config tooling
- Weather integration (design drafted 2026-07-28, see HIKER_SAFETY.md)
- Any in-app purchases (see business model below)
- No purchases, subscriptions, tips, or payment prompts inside the mobile app shell — this avoids the ~15-30% Apple/Google App Store cut, so more of every dollar reaches the trail clubs.
- Any paid tier, donation flow, or sponsorship purchase lives on the web version only. The mobile app can link out to the web for that.
- Per value #5, this is about sustainability, not paywalling safety data — core map/POI data stays free everywhere; monetization is additive (e.g., donations, maybe premium convenience features later), never a gate on safety-relevant info.
- Longer-term intent: revenue should flow toward funding ATC / affiliated maintaining clubs, not just cover OurHike's own hosting costs.
- Trail POI data (centerline, side trails, shelters, campsites, viewpoints, parking, communities): from the ATC's own public GIS map (ArcGIS-hosted: arcg.is/1nqL542, 9 layers cataloged programmatically — see
pipeline/) — the same authoritative source FarOut itself uses. The ATC has maintained this data since 1998. Exact redistribution terms still need to be confirmed with ATC directly; the user can help pull the data or make an introduction. Confirmed gap: ATC's data has no dedicated water-source or general resupply layer. - Water sources & resupply POIs (filling the gap above): OpenStreetMap tags (
amenity=drinking_water,natural=springfor water; shops/post offices/hostels for resupply) plus USGS hydrography (streams/springs) as an approximate water proxy. Both are unverified/approximate, not confirmed-current data — the UI should be honest about that distinction (value #4), not present them with the same confidence as ATC's official facility data. - Offline base map tiles: USGS US Topo / National Map raster tiles (apps.nationalmap.gov/downloader), clipped to the corridor — public domain, pre-rendered, the topo format hikers already trust. OpenStreetMap is deliberately not used for the background map (see TECHNICAL_ARCHITECTURE.md for the raster-vs-vector reasoning) — its role is limited to the supplementary POIs above. Scoped to a ~30-mile corridor around the trail and its waypoints only — not full state/regional coverage. This keeps offline downloads small for hikers and hosting costs low (value #8), while still covering everything within a reasonable resupply/support range of the trail.
Given the "one codebase" preference, needing phone + web day one, no in-app purchases, and the values around sustainability (#8) and being inheritable by other volunteer-run clubs (#7), my recommendation:
A Progressive Web App (PWA) — a single web codebase (e.g., React/TypeScript) using MapLibre GL JS (open-source map renderer, no vendor lock-in, unlike Mapbox or Google Maps) for the map itself, with offline map data shipped as PMTiles (single static archive files — no tile server to run or pay for, which fits the bounded 30-mile-corridor dataset well). The same codebase is wrapped with Capacitor to produce installable iOS and Android app shells for the app stores, so hikers can still find and install a "real app" — just built from the one web codebase, not a second implementation.
Why this over Flutter or React Native: it draws from the largest possible volunteer developer pool (plain web skills are far more common than Dart or React Native's native-module knowledge), everything in the stack is fully open source with no vendor lock-in, and it sidesteps app-store complexity entirely for anything except distribution — which matters since no purchases happen in the app anyway.
Trade-off to know about: continuous background GPS track-recording (tracking your route while the phone is locked in your pocket) is weaker in a PWA/Capacitor app than a fully native one. Foreground use — open the app, see the map, see "you are here," look up nearby water/shelters — works fine with this approach. If background track-recording becomes a priority later, Capacitor supports native GPS plugins to close most of that gap without a rewrite.
Pulled from Zoe Symon's Guthook Guides (now FarOut) redesign case study (2026-07-25) — a UX case study on the app we're most directly positioned against, worth referencing again later. Cross-cutting design guidance, not phase-specific:
- "Use the app less often, and find information faster when you do." Optimize for quick lookups, not session time/engagement metrics — the opposite of typical app growth goals, and a natural fit with value #1 (hike your own hike): no reason to manufacture engagement.
- Architect for extensibility from day one. Guthook's original build reportedly lacked this and it limited later feature work — validates our existing instinct (unified POI schema, avoiding AT/NYNJTC-only assumptions per value #7) rather than introducing something new.
- Community features should be core, not bolted on. Their research found thru-hiking is inherently social — direct validation of the commenting/upvoting/guides items under Community reporting below.
- Fast, low-friction onboarding — minimal setup before the map is usable, no heavy signup wall blocking time-to-value. Fits our no-account-needed PWA approach.
- Separate "available" from "owned/downloaded" content clearly — relevant once we have per-section downloads or any paid tier, so users aren't confused about what they already have.
- A good feature undermined by poor discoverability is its own failure mode. Their route-creation tool was well-liked but hard to find — worth designing findability in explicitly (e.g. for our own trip-planning tools under Extras below), not just building the feature and assuming it'll be found.
- Process note, not a feature: they ran open-ended surveys across thru-hikers/section-hikers/day-hikers before designing anything — worth doing something similar once NYNJTC's soft launch gives us real users, rather than guessing at priorities.
Grouped by value, for later prioritization — not committed, just not forgotten.
- Design drafted 2026-07-28: see AUTHENTICATION.md. Google/Apple/email sign-in, email verification, optional MFA, recommended technical approach (Supabase Auth). Doesn't change the MVP's no-account-needed principle - this is foundational for Segments (cross-device sync), Volunteering (club admin access), and Report a Problem (reporter identity), so it should be the first Post-MVP feature actually built, ahead of the three below that depend on it.
- Hiker-submitted condition reports (text + photo), with timestamp + reporter type shown. Design drafted 2026-07-28: see REPORT_A_PROBLEM.md - report types (blow downs, trash, bad hikers, flooding, shelter repair, animals), pick-a-location flow (existing POI, dropped pin, or current location), and a path toward richer type-specific follow-up over time.
- Maintainer verification/flagging workflow
- Moderation queue for club admins
- Link between hiker reports and official trail-maintenance logs
- Club data-entry tooling (2026-07-24): local ATC-affiliated clubs need a way to directly add/edit their own shelters, water sources, campsites, and other trail features - not just via the GIS pipeline, which only they (not volunteers at large) can realistically operate. This is the actual mechanism behind "per-club admin roles" below, made concrete.
- Community submission + upvoting (2026-07-24): beyond condition reports, let community members submit their own POIs/corrections and have other members upvote them - a lightweight trust signal ahead of full maintainer verification. Needs a spam/abuse-resistant design before it ships (value #4 - trustworthy above all - means a wrong upvoted submission is worse than no submission).
- Place-based social commenting, FarOut-style (2026-07-24): comment threads tied to a specific map location, not just structured condition reports. This is the single feature most directly competing with FarOut's actual daily-use appeal, so it matters a lot - but it also sits in the most direct tension with value #9 ("be magical," not just have a magic feature): unmoderated place-based comments are exactly the kind of feature that can tip into the things value #9 explicitly warns against (broadcast/overcrowding pressure, unattended-cache-style posts, oversharing). Needs real moderation/design thought before building, not just a clone of FarOut's comment UI.
- User-generated guides (2026-07-24): let hikers compile their own guides/route collections from the underlying data (a bigger, more curated unit than a single comment or report) - e.g. "my recommended water sources for a NOBO thru-hike." Not scoped further yet; revisit once the underlying POI/reporting data model exists to build on.
- Low-friction data-freshness prompts, encouraging (never requiring) hikers to confirm water/shelter/resupply conditions or check off a resolved report. Design drafted 2026-07-28: see DATA_NUDGES.md - deliberately not a notification of any kind, just visual prominence on the map for data that's gone stale; the actual data-collection mechanism Water Reliability Prediction below already assumes exists.
- Serious-tier warning pins (bear sightings, dangerous humans, blow downs) escalated from Community reporting's existing types via moderation, not self-declared; a configurable anonymity window for comment name/date; a responsibly-sourced NWS weather-alert relay plus elevation-aware daily conditions; and a deliberately conservative wrong-way/off-trail alert - explicitly scoped as the only notification OurHike ever sends. Design drafted 2026-07-28: see HIKER_SAFETY.md.
- Predict whether a given water source is likely flowing or dry right now, rather than just showing the last static entry. wikitrail.org's own founding story is literally a hiker hitting a "should be flowing" water source that was dry - this is a real, recurring failure mode of static trail data, not a hypothetical.
- Likely inputs: historical hiker reports (frequency/recency of "dry" vs "flowing" reports at a source), seasonal/precipitation patterns, and possibly NHD stream classification (perennial vs intermittent) already noted as a data source in TECHNICAL_ARCHITECTURE.md. The "historical hiker reports" input has a real collection design now: see DATA_NUDGES.md.
- Directly extends value #4's existing "reported 3 days ago vs. confirmed today" idea from a passive timestamp into an actual predictive signal - but the bar is high: a confidently wrong prediction is more dangerous than an honest "unknown," so this should ship after there's enough real report volume to back it, not as a launch feature.
- User-selectable background tile source, plus roads/sidewalk-walkability and trail-closure overlays. Design drafted 2026-07-28: see MAP_OPTIONS.md - free/live-tile-API options researched directly (USGS's own live service recommended; OSM's raw tiles and Esri's imagery both ruled out for this use, commercial OSM-styled options gated behind a real terms conversation), an honest walkability signal for trail-to-town road walks, DuckDB-backed snap-to-trail for Segment boundaries, and trail-closure marking/display for storm damage and reroutes - flagged there as possibly deserving the same MVP-promotion conversation elevation got, not decided in this list.
- Point-in-time help requests/offers between hikers — ephemeral, expires automatically, never a persistent pin
- Explicitly excluded, permanently: any feature for broadcasting unattended caches ("food left at mile X")
- Volunteer-opportunity surfacing (trail maintenance workdays, club events). Design drafted 2026-07-28: see VOLUNTEERING.md - a club-side work-project management module, plus (the more important half) upcoming projects shown on the map to encourage hikers to join one.
- Hiker-friendly local business directory
- Contextual Leave No Trace reminders (e.g., bear-country food storage) tied to location/season
- No location-sharing or contact exchange without explicit, per-instance consent
- User data export (routes, saved hikes) in open formats (GPX/GeoJSON/CSV)
- Public read API for trail/POI data
- Documented, versioned open data schema
- Org/club as a first-class data model concept — trails and POIs scoped to a club/region
- Per-club admin roles
- Onboarding path for the next ATC-affiliated club with no NYNJTC-specific assumptions baked in
- Persistent light/dark/metric-units preferences, which waypoint types display and at what label density, and auto-rotate (heading-up map orientation). Design drafted 2026-07-28: see UX_CUSTOMIZATION.md - leads with a real planning distinction (persistent settings vs. momentary on-map controls, and app-wide preferences vs. map-specific ones) before the individual toggles, and takes auto-rotate's real platform difficulty (no built-in MapLibre support, a genuine iOS/Capacitor permission dependency) as seriously as the wrong-way alert's.
- Elevation profiles per trail/section
- Trip planning tools (distance, elevation gain, estimated time) — informational, not prescriptive (no streaks/leaderboards, per value #1). Design drafted 2026-07-28: see SEGMENTS.md (the underlying hierarchical Hike/Segment structure - a "segment" means a day to a thru-hiker, a leg between landmarks to a day-hiker) and TRIP_PLANNING.md (waypoint-based day-hike planning, bulk multi-day adjustment, POI-aware planning assistance, and a distance/elevation-gain-and-loss difficulty estimate, honest about what it can't capture).
- Weather overlay relevant to trail conditions