The back office behind the cockpit

The flight lands. The school already knows.

MasterPilot's app is the cockpit: it records, replays, and grades the flying. That half is the client's. We built the back office: the portal where schools run licenses, people, fleet, and campuses, and the pipeline that carries every flight from webhook to inbox.

Scope

What we built, and what we didn't

MasterPilot is not our product. We were brought in for the portal that runs the schools: management, reporting, and the automation behind them. This page covers that build, and nothing else.

SystemStatus
School portalLIVE
Webhook syncLIVE
Reporting engineLIVE
Email engineLIVE
Auth and auditLIVE
The iOS appCLIENT
The marketing siteTHIRD PARTY
10 releases, December 2024 to June 2026 · In production since March 2026
The problem

Everything existed. Nothing was connected.

The app graded every flight in the air. On the ground, the school ran on manual lists, separate campus systems, and licenses that died with every departure.

A student pilot flying with a headset and tablet

Licenses walked out the door

Every seat was glued to a person. When someone left, the seat left with them.

Aircraft wing above the clouds at sunset

Every campus was an island

People lived in manual lists. Aircraft had no link to the school. Each location ran its own system.

Cockpit instrument panel in flight

No system knew the school

The app knew the flights. The lists knew the people. Nothing put quality, activity, and spend in one place.

The handoff

What happens when a flight lands

The app and the portal are separate systems with no shared database. Webhooks carry everything both ways. From the moment a flight lands, nothing waits on a person.

  1. 01

    Before the flight

    The portal has already shaped this cockpit: license, role, course, and fleet, pushed over webhooks.

  2. 02

    The webhook fires

    The flight arrives at the portal endpoint, alone or in a batch.

  3. 03

    Saved before parsed

    The raw payload writes to ApiWebhookLog before a single field is read.

  4. 04

    The job runs

    A dedup key, three attempts, a status state machine. Failure means replay, not loss.

  5. 05

    Reports refresh

    Hours, scores, and medals land in 13 pre-computed cache tables; a dirty flag marks what must recompute.

  6. 06

    The mail goes out

    An email per processed flight, each carrying an idempotency key; a distributed lock keeps the cron from sending twice.

The parse can be wrong. The record never is.

The console

Eight screens a flight school runs on

The portal is the back office, the app is the cockpit. No shared database, webhooks in both directions. We built the back office. These are its eight screens. Pick one.

MasterPilot instructor list: every instructor with their student count and hours
01 / 08

Every instructor on one board.

The whole faculty, their student load and hours flown, sortable in a single view.

Campus scope guards run on every mutation, so one campus never sees another.

The mail room

Nobody spammed, nobody forgotten

A master switch stops everything. Per person toggles and bulk controls tune it. Every user can opt out per email type. The automation runs itself; the owner holds the remote.

JobStatus
INSTRUCTOR REPORT
STUDENT FLIGHT EMAIL
STUDENT FLIGHT EMAIL
MASTER SWITCH

One row per email, an idempotency key on each, a distributed lock on the cron, and a circuit breaker when a provider fails. Postmark and AWS SES carry the mail.

The pre-flight checklist

Six decisions we would defend in review

Not a feature list. These are the engineering calls behind the portal, and the reasoning we would give if you challenged each one in review.

  • A job queue in the database

    Not Redis, not SQS. Dedup keys, three attempts, a status machine, one less system to operate.

  • Log the payload before parsing it

    Every flight lands raw in a webhook log first. If processing fails, we replay from the raw record.

  • Licenses belong to the school

    When someone leaves, the seat returns to the pool and is reassigned. No departure wastes a seat.

  • Reports read from cache first

    13 pre-computed tables return instantly. TTL plus a dirty flag set by mutations keeps them current.

  • Passwordless login, magic links only

    No passwords are stored anywhere, so there is nothing to steal, nothing to leak, nothing to reset.

  • Scope guards on every mutation

    Each campus is walled off and every write is checked. Data cannot leak between campuses.

Aircraft wing above the clouds at sunsetRESULT

The school runs from here

The portal is the back office: licenses, roles, fleet, and campuses are set once, and every cockpit follows. We shipped it across ten releases, and it has run in production since March 2026.

Endpoints
129
Modules
23
Cache tables
13
Live since
Mar 2026
Built by
HorizonLux
SCHOOL PORTAL
WEBHOOK SYNC · EMAIL ENGINE

Everything exists. Is it connected?

Most teams do not need another system. They need the ones they already pay for to talk to each other. Tell us which two of yours still do not, on a free 20 minute call.

Prefer email? [email protected]