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.
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.
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.
Licenses walked out the door
Every seat was glued to a person. When someone left, the seat left with them.
Every campus was an island
People lived in manual lists. Aircraft had no link to the school. Each location ran its own system.
No system knew the school
The app knew the flights. The lists knew the people. Nothing put quality, activity, and spend in one place.
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.
- 01
Before the flight
The portal has already shaped this cockpit: license, role, course, and fleet, pushed over webhooks.
- 02
The webhook fires
The flight arrives at the portal endpoint, alone or in a batch.
- 03
Saved before parsed
The raw payload writes to ApiWebhookLog before a single field is read.
- 04
The job runs
A dedup key, three attempts, a status state machine. Failure means replay, not loss.
- 05
Reports refresh
Hours, scores, and medals land in 13 pre-computed cache tables; a dirty flag marks what must recompute.
- 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.
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.
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.
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.
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.
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.
RESULTThe 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.
WEBHOOK SYNC · EMAIL ENGINE
See also
More of our work.
RepairCheck Dashboard
Admin panel behind the RepairCheck mobile app.
View case study
Tabeebi
Healthcare booking platform built for the UAE, holding three sides to one calendar: the clinic that owns the schedule, the doctors who work it, and the patients booking them.
View case study
RepairCheck
Vehicle inspection app for automotive experts.
View case studyEverything 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 30 minute call.
Book a Free 30-Minute Call
We map one workflow that eats your team’s week and show you what an engineer and a few AI agents could take off it. No slide deck, no sales pitch. Just a working session.
Don’t want a call? Email [email protected]
Book a free call- One workflow mapped with you, live
- A clear first step for your team
- Reply within one working day
We worked with Seif on the React Native app for our vehicle-appraisal platform. What stood out most was how much ownership he takes: he thinks a feature through, raises edge cases before they turn into bugs, and delivers something that actually works. And then there is one more thing why I wanted to work with Seif after our very first call: Exceptional clear and consistent communication. It is a pleasure to work with him and his team!
Michael EmaschowFounder, RepairCheck
Seif SgayerFounder ·View LinkedInFree Strategy Call
30 minutes · Google Meet · Free
No packages, no sales pitch. You leave with a clear first step.
- 30 min
- Google Meet
- Calendly
- No commitment
- The plan is yours to keep
- Built for teams at Tabeebi, RepairCheck and MasterPilot