Soar
SoarFleetSchedule PlanWeather
In development

Plan at a desk. Fly on the iPad.

Serious planning doesn't happen on a seven-inch screen at the aircraft. It happens the night before, at a keyboard, with a chart open and a coffee going cold. Soar Plan is that screen — the same terrain, turbulence and obstacle intelligence as the app, with room to actually think.

Tell me when it's ready Use the app today

Browser-based. Nothing to install.

Why a second screen

The tablet is a flying instrument, not a drafting table.

In the aircraft you want the map, the next waypoint and the thing about to hurt you. On the ground you want to compare three routings, check terrain against four wind scenarios and brief a crew. Those are different jobs and they want different screens.

Planning today
  • Pinching a route into shape on a tablet, on a bench
  • Chart on one screen, weather on another, notes on paper
  • Briefing a crew by reading numbers aloud
  • The plan lives on one person's device
  • Nothing to hand the client except a screenshot
With Soar Plan
  • A full-size map, keyboard shortcuts, several routes side by side
  • Terrain profile, weather and hazards in one view
  • Send the whole plan to the crew's app — waypoints, sketches and all
  • Published routes reach every pilot in the operation
  • A printable brief, and a track to compare against afterwards
How it works

One brain, two screens.

The temptation with a web version is to rebuild the planning logic in a second language and end up with two planners that quietly disagree about fuel reserves. We're not doing that.

  1. The planning engine moves to the server

    Route generation, terrain routing, turbulence, weight and balance, weather decoding — one implementation, called by both the app and the browser. Change a rule once and both get it the same day. There is no version of this where the web says one thing and the iPad says another.

  2. Alerting stays on the aircraft

    Proximity alerting never becomes a network call — the whole point is that it works in a valley with no signal. That logic stays on the device, permanently. The browser doesn't need it, for the same reason nobody flies with a laptop.

  3. Plans sync both ways

    Build it at the desk, open it in the aircraft. Change it at the aircraft, and the operations desk sees the change. For fleets, a published route reaches every pilot's app without anyone emailing a PDF.

Planned capability

What you'll be able to do.

Full-size map

Airspace, TFRs, terrain, wire spans and your own waypoints — with the screen space to see all of it at once.

Compare routings

Two or three options side by side, with terrain profile, exposure and time for each.

Vertical profile

What you'll clear along the route, and what you won't, at the altitude you intend to fly.

Weather scenarios

Run the same route against different wind and ceiling assumptions before committing to a departure time.

Crew briefing

A shareable brief — waypoints, sketched approaches, hazards and notes — that opens in the crew's app in place.

Fleet routes

Publish a standard routing once; every pilot in the operation has it. Tied into Fleet.

Honest about where this is.

Soar Plan is in development and doesn't exist yet. The data behind it does — the hazards, airspace, terrain and weather are live and serving the app today — and so does the planning logic, currently on iOS. The work is moving that logic server-side and building the browser client on top.

If desk-based planning is the thing standing between you and using Soar across an operation, say so. That moves it up the list.