How an Aircraft Management Company Replaced a $950 a Month Subscription With Its Own Owner Portal

An aircraft management company at a Phoenix-area airport looks after a fleet of privately owned aircraft. Ten owner entities, eleven aircraft. Owners tell the company where they want to go. The company confirms the trip, assigns crew, arranges the ground details, and flies it. Pilots log what happened afterward.

To run that, the company paid $950 a month for an aircraft-management subscription. The owner-facing piece of it was a public trip request form, which the company embedded in a password-protected page on its website. One password, shared by every owner.

What was breaking

• The tool couldn't tell owners apart. The vendor allows one shared public request form per account, and confirmed to us that there's no way to limit which aircraft a given person sees. Every owner picked from the full fleet, and staff reassigned the aircraft by hand when they built the real trip.
• A shared password isn't an account. No record of who requested what, no per-owner view of a schedule, nothing to revoke when an owner sells an aircraft.
• Scheduling lived in two calendars. The subscription's calendar and the owner's own, reconciled by hand.
• Passports and passenger details had no proper home. International trips need passports. Storing them safely, with an audit trail and a retention policy, wasn't something the subscription did for them.

The company was paying $950 a month for a fleet calendar and a request form, and working around both.

What we built

A custom web application, hosted on Railway with a Postgres database, that the company owns outright. It was scoped in a single interview on August 13 and demoed to the owner on August 24. Here's what's in it.

For owners

• Individual accounts. About 10 to 15 at launch. An admin creates the owner, assigns their aircraft (owners can share an aircraft and an aircraft can have several owners), and sends an invitation.
• A trip request form built for how aviation trips actually work. One-way, round-trip, or multi-leg. Per-leg airports, dates, and departure times, with "flexible" allowed. Passengers picked from a saved list with per-leg toggles, so someone can be on the outbound and skip the return. Extras as checkboxes: rental car, catering, baggage, pets, special requests. A notes field.
• Destination lookup that accepts an address. One field takes a city, airport, or FBO, backed by 85,901 airports loaded from open data. An owner can also type a street address and leave the arrival airport blank. The system finds the nearest suitable airport, records it as a real leg, and shows staff a "to be confirmed" flag.
• A calendar of their aircraft's full schedule. Other owners' trips on a shared aircraft show as opaque blocks with no names or details. We verified the page delivers no other owner's personal information.
• A "your trips" page with upcoming and past trips and yearly rollups: trips, flights, hours flown, nautical miles, airports visited, top destination.
• A profile that stores rental-car loyalty numbers, so staff stop booking cars on personal accounts and transferring them.

For staff

• Confirm or decline from email. A request triggers a staff notification with Confirm, Decline, and View request buttons. Clicking one requires an admin sign-in, then the decision is recorded with a name on it. Trips move through Requested, Reviewing, Confirmed, Declined, and Completed, with a full status history.
• A fleet calendar and an ops dashboard with a "flights without crew assigned" tile. Crew assignment stays manual by the owner's choice, as a quality check. Assigned crew get a "You're on a trip" email with schedule facts only, no passenger names.
• A double-booking wall. Two confirmed trips can never overlap on one aircraft. The check runs under a database lock per aircraft, so two staff members confirming at the same moment can't slip past it.
• Roles and permissions. Admin, view-only, crew (dashboard, calendar, and trips, read-only), and a maintenance role ready for later. A settings screen controls which navigation each role sees.

For pilots

Pilots log in and file a short post-flight log: times, fuel burn, landings. Aircraft totals only move when a flight is logged, so the counters can be trusted.

Automated itineraries

Seven days before departure, and again 48 hours before, crew and passengers get an itinerary email with the full per-leg plan and two buttons: view trip details, or modify or cancel. A change request opens a new request tied to the original. The original stays booked until staff confirm the replacement, so nothing gets cancelled by accident. An hourly job on Railway sends these, and a dry-run command previews exactly what the next run would send, with no side effects.

Passports, done properly

Passport numbers are encrypted at rest with AES-256-GCM. Scans go into a private storage bucket and are only served through one audited endpoint that issues short-lived signed links. Passengers can upload their own passport through a tokenized page, so staff never handle the file by email. Uploads are gated behind a published privacy policy and retention rules. Phone photos in HEIC format are converted on the way in. And passports are only requested for international legs. A domestic trip never nags anyone for one.

Monitoring

Error monitoring is on, with personal data collection turned off. A health endpoint reports whether migrations are current and required settings are present. The hourly job checks in with a heartbeat monitor, and a watchdog fires if it goes 50 minutes without one, so a silent failure gets noticed. And every change to how a trip renders on screen is mirrored in the email templates in the same batch, so the inbox and the app always tell the same story.

How it runs day to day

1. An owner signs in and requests a trip. They get a receipt email with the itinerary as requested.
2. Staff get a notification, sign in from the email, and confirm or decline. If the request would overlap another confirmed trip on the same aircraft, they see the conflict before deciding.
3. The owner gets a confirmed (or declined) email with a clean itinerary.
4. Staff assign crew. Crew get their schedule by email.
5. At 7 days and 48 hours out, everyone on the trip gets the itinerary again, with a way to flag a change.
6. After the flight, the pilot logs it. The trip moves to Completed and the aircraft totals update.

What changed

The owner agreed on the demo call that the software will replace the subscription. The rollout is phased on purpose: test with dummy data first, then run the new system in parallel with the subscription, then migrate fully. As of this writing the company is in the testing phase with real staff accounts, and the subscription is still running alongside it.

What the company gets at the end of that is a request form that knows who's asking, a schedule owners can actually see, a confirm-or-decline step that takes one click, itineraries that send themselves, and a passport process with an audit trail. The ongoing cost is hosting and email delivery. Next on the list, in the owner's priority order: Google Calendar sync, a staff-only documents shelf, and text-message notifications.

What this means for you

If you're paying a meaningful monthly fee for software and using a small slice of it, or working around it with shared passwords and side spreadsheets, custom software may cost less than you think, and it will fit. It isn't the answer for everything. We wrote up how we make the call in when to replace a SaaS subscription with custom software, and when not to.

The free 30-minute audit is the right first step. We'll look at what you pay for, what you actually use, and whether a build makes sense. Book a free automation audit.