An internal operations platform I designed and built for Alaska Backcountry Access: live Xola bookings alongside weather, avalanche, and trail intelligence, fleet and dispatch, maps, and a custom CRM, one screen instead of a dozen tabs.
Part of Alaska Backcountry AccessThe business
Alaska Backcountry Access runs its day-to-day across a dozen disconnected places: Xola for bookings, separate sites for weather, SNOTEL, and avalanche conditions, spreadsheets and notes for fleet and dispatch, and scattered files for customer history. Deciding whether a tour is a GO meant checking five tabs and remembering the sixth.
The real problem
Pull the operational picture into one screen (bookings, conditions, fleet, and customers) without faking data the business doesn't have, and without turning a real operating tool into a brittle demo. It had to use production booking data honestly while clearly showing which parts are live and which are still being wired up.
My responsibility
The whole platform: architecture, the live integrations, the booking and CRM data model, the maps and dispatch views, the webhook/automation service, and the test suite that keeps it from breaking silently.
What was built
01
A daily brief that combines live Xola bookings and manifests with weather, SNOTEL snow depth, avalanche danger, NWS alerts, fleet readiness, and a tour GO/CAUTION/NO-GO recommendation scored against current conditions.
02
Live booking data, calendars, manifests, and customer history pulled from the real Xola account, the system reports READY when the production connection is healthy, not as a hard-coded label.
03
A live operations map (Leaflet) with meetup locations and trail routes, plus SNOTEL, CNFAIC avalanche, NWS, and aviation feeds, the conditions a backcountry operator actually decides on.
04
Machine readiness, maintenance and service flags, dispatch planning, trip logs, and performance views for the operational side of the business.
05
A modular CRM with its own database schema, API routes, migration contract, and Postgres rehearsal tooling, contacts, conversations, leads, tasks, follow-ups, and outcome metrics. Designed as an extractable service within the larger platform, not yet a separately deployed app.
06
Fake alerts and misleading 'all systems operational' messaging were removed; actions that need credentials (cloud editing, dispatch sending, OpenPhone SMS) are disabled until those credentials exist, so the UI never implies a capability that isn't wired up.
System view
Production Xola bookings and manifests; SNOTEL, CNFAIC avalanche, NWS, and aviation feeds; fleet and inventory records.
A Streamlit interface plus a Flask webhook/automation service pull it together with a durable database and migration tooling.
Daily brief, tour GO/NO-GO scoring, dispatch planning, and customer follow-up, the calls the business makes every morning.
Inspectable proof
Sanitized artifacts show the underlying work without exposing client identities, credentials, private dashboards, or customer data.
Fresh status from the latest build and live test pass. Production booking data is real; everything is labelled by what is actually wired up.
This case separates what is built and production-connected from what is still being wired up.
The real dashboard on a quiet day: live Xola booking status (no bookings today), weather and fleet readiness, and GO/CAUTION/NO-GO scoring for the outfitter's own tours against current conditions. The state reflects what the integrations actually report, not a hard-coded 'all systems operational'.
A real screen from the running tool: the Leaflet operations map with loaded meetup locations, plus the trail-intelligence panel drawing on SNOTEL, CNFAIC avalanche, and NWS feeds. No bookings or customer records are shown.
The operations platform in a responsive mobile layout, live map, assets, guest list, and dispatch tabs with bottom navigation. No customer data is shown.
Evidence
The platform connects to the real Xola account and reports READY; live testing loaded Xola status, weather, NWS alerts, SNOTEL, fleet data, and tour recommendations.
116 tests passing, 1 skipped, application compiles successfully; the CRM migration contract passes.
SQLite CRM tables, deduplication, follow-ups, and lead tracking with Postgres migration tooling are implemented, but the database holds no real contacts, messages, leads, or outcomes yet.
Inbound/outbound SMS architecture is built and OpenPhone-ready, but credentials and live testing are pending, the largest remaining business workflow.
Authentication, shared cloud editing, and the automation/deployment service are pending configuration; the runtime still uses SQLite rather than the prepared Postgres path.
Results & current state
The scattered operational picture lives on one screen, built on real booking data.
Production Xola integration reports READY; the dashboard combines live bookings with weather, avalanche, fleet, and tour-decision intelligence.
It's engineered to last, not demoed to impress.
116 automated tests, a durable database with migrations, webhook security, and a CRM migration contract that passes, with fake alerts and misleading status removed.
The CRM is real architecture, honestly staged.
A modular CRM Core with its own schema, API routes, and Postgres tooling, designed as an extractable service, presented as built-but-not-yet-populated rather than overstated.
Describe your setup in a few sentences. You'll get a plain answer about whether and how I can help.