Why Build a Fake Helicopter Operations Platform

Let's get the obvious question out of the way first: Clearspar Heli is not a real business. There's no helicopter, no heli-ski operator, no guest booking a real trip. Every aircraft, pilot, guide, and guest in the demo is invented sample data, generated to populate the screens with something realistic-looking. It is not affiliated with any real operator, and it is not a certified operational safety system — nobody should use it to actually run flights. It's a portfolio project: a prototype built to demonstrate product thinking and engineering judgment in a domain that happens to have real stakes.

That last part is the actual point. Most portfolio projects are CRUD apps with a todo list or a blog wrapped around them — fine for showing you can wire up a form, but they don't force any interesting decisions. A day-of-operations platform for a heli-ski or heli-charter operator is different. If a check-in screen lies about whether an action succeeded, or a permission check is missing on the wrong button, the failure mode isn't “the demo looks slightly wrong” — it's the kind of thing that matters when the underlying activity is people getting into and out of a helicopter on a mountain. Building in that domain, even as a simulation, means you can't hand-wave the boring-but-critical stuff: who's allowed to do what, what happens when the network drops, what the system does when it doesn't know the answer.

What “day of ops” actually means. For an operator like this, a single day involves a fair number of moving, interdependent pieces: assigning guests to groups and aircraft with real weight-and-balance and cargo-bay constraints, tracking where every aircraft is and what phase of flight it's in, making sure field guides check in on a schedule and someone gets alerted if they don't, logging maintenance discrepancies before they become the reason an aircraft can't fly, and reconciling all of it into a closing report at the end of the day. None of these are independent — a weight-and-balance sign-off references a real pilot; an escalation depends on the same check-in data the guide sees on their phone; the debrief report has to come from the same live data as the boards, not a separately hardcoded summary. That interdependency is what makes it a real system rather than a set of disconnected screens.

What actually got built. The platform covers a Scheduling & Manifest Board for the helicopter and snowcat fleet, live Flight-Following & Dispatch with per-phase check-in escalation, a stripped-down mobile Guide View that shows a field guide only their own group's check-in action and medical/dietary flags, and an End-of-Day Debrief generated from that same live data. On the safety and compliance side there's a Part 135-style duty-hours log, an MEL/squawk board for aircraft discrepancies, an avalanche-control shot log, a guide certification/currency tracker, an incident/near-miss log, and weight-and-balance sign-offs with real pilot attribution. Underneath the operational screens sit the things that make a multi-tenant system trustworthy: a role-by-capability permission matrix that mirrors the actual server-side checks, an append-only audit log, GPS breadcrumb history with scrub-and-replay, an offline map-tile cache, and a scoped public webhook/API surface for integrations.

You can walk through all of it on the live demo.

Two follow-up posts go deeper on specific problems that came up while building this: one on a permission bug that let the wrong role clear an aircraft back into service, and one on how multi-tenant data isolation was enforced at the database level — and a bug class that decision kept producing.