FAQ
What is Clearspar Heli?
It's a portfolio prototype — a day-of-operations platform for a heli-ski / heli-charter operation, covering scheduling, live flight-following, safety and compliance logging, and team comms. It was built to demonstrate full-stack engineering — backend, database design, real-time systems, offline support, and security — against a domain with genuine safety-critical stakes, not to launch as a business. Every screen runs real code against a real database; it's just not a real company.
Is any of this real — the aircraft, the guests, an actual operator?
No. Every aircraft, pilot, guide, and guest in the demo is invented sample data, and the platform isn't affiliated with, built for, or representing any real heli-ski or charter operator. It's also not a certified operational safety system — it's a demonstration of how you'd build one. Nothing here should be read as evidence of a real customer, real usage, or real revenue.
Why does the demo show a full heli-ski day in the middle of summer?
Because the demo calendar re-anchors to today every night, so the day you land on is always the current one rather than a fixture that quietly went stale. That part is deliberate: an earlier version was seeded once and twelve days later still labelled a past date “Today”, which meant post-trip surfaces fired for guests who hadn't flown yet — every value was real, but the calendar underneath them had rotted. The trade-off is that out of season you'll see an operating day dated when nobody would actually be flying powder; a real Chugach/Valdez-style season runs roughly March through April. Read the dates as “day one, two, three of an operating week”, not as a claim about the weather outside.
What's under the hood?
FastAPI (Python) and async SQLAlchemy over Postgres on the backend, with a statically-exported Next.js frontend served same-origin by FastAPI. Multi-tenant isolation is enforced at the database layer with Postgres Row-Level Security, keyed on a per-request session variable, rather than filtering in application code. Live updates run over Server-Sent Events (in-process by default, swappable for Redis pub/sub across workers). The live map is MapLibre GL over real Esri satellite imagery; positions come from an AFF-standard ingest adapter (the format Spidertracks, TracPlus, and SKYTRAC speak) — a complete HTTPS transport and XML parser that runs a labeled sample feed in the demo and flips to a live operator feed with three env vars — plus an optional supplementary OpenSky ADS-B fill-in. Every fix is badged with its source (sim / sample / live) so provenance is always visible. It deploys as Docker containers on a self-managed Linux host.
Why build something in this specific domain?
Day-of-ops for heli-ski or heli-charter flying is a good stress test for engineering discipline: weight-and-balance math and cargo-bay limits have real consequences, check-in escalation has to actually escalate, and a permission mistake — like letting the wrong role clear an aircraft back into service — isn't just a cosmetic bug. Building at that stakes level forces RLS-based tenant isolation, honest offline handling, and role-based access control to be load-bearing rather than decorative.
Is it safe to click around in the demo?
Yes. Sign in with any of the sample role logins on the sign-in screen (ops manager, dispatcher, guide, pilot) — no real signup or payment involved. The Twilio SMS integration for escalation alerts only activates once real credentials are configured, which they aren't here, so no action ever texts a real phone. Some actions are gated by role, the same as they would be in a real deployment — that's the point being demonstrated, not something hidden from the demo.
What happens if I go offline in the field or guide view?
The app is an offline-first PWA — a service worker caches the app shell so it loads without a connection, and any writes you make, like a check-in, are queued in IndexedDB and replayed automatically once you're back online. Rather than pretending everything is synced, the UI is upfront about it, showing something like “N changes queued, last synced Xm ago” so the real state is never hidden.
What's the most interesting bug you found building this?
The “resolve a squawk” action, which marks a helicopter airworthy again after a maintenance discrepancy is fixed, shipped with no role check at all — any authenticated staff account, including a field guide, could clear an aircraft back into dispatchable status. It was found during a systematic pass looking specifically for actively-misleading behavior, fixed by gating it to the ops_manager role to match the adjacent “defer under MEL” action, and verified by re-running the exact exploit against the live production API: a guide credential got a real 403, a manager credential got a real 200 with the resolution correctly attributed to them. A few other real ones turned up too, including an SSRF/DNS-rebinding gap in the public webhook feature and a check-in button that showed “success” before the server had actually confirmed it — more on those on the blog.
Is it finished? What's next?
Every module described on the home page — scheduling, dispatch, safety and compliance, team comms, staff and access, audit logging, breadcrumb history, and the public API — is built and live in the demo. As a portfolio piece rather than a shipping product, it doesn't have a fixed “1.0” cutoff; treat what you see as a working snapshot of ongoing engineering work, not a finished, closed product.