Most of what we do is connect the tools a business already has and make the repetitive work run itself. But every so often we hit a business where the core tool is the problem: it's expensive, it's awkward on a phone, and the owner is doing double data entry to work around it. When that happens, the highest-leverage move isn't another integration. It's building the thing properly.
This is the story of one of those builds: a Part 91 aircraft management company in Arizona that manages a fleet of private aircraft for their owners, handles the trips, crews, maintenance tracking, and accounting, and was paying about $950 a month for legacy scheduling software that everyone on the team disliked.
The situation
The operator's day looked like this. An aircraft owner texts or calls to request a trip. The operator builds the trip in the scheduling platform: legs, airports, times, crew, passengers. Then rebuilds the same trip in a second tool to notify the FBO and book a rental car, which doesn't attach to the trip. After the flight, the pilot hand-keys hours, landings, and cycles into the scheduling platform, and then the operator hand-keys them again into the maintenance tracking system so inspection alerts fire. The 48-hour trip confirmation to passengers and crew is triggered manually. The mobile app is an unformatted web view that pilots avoid.
Every trip was built twice and every flight was logged twice. And the platform doing this cost $950 a month.
Step one: the website
Before the portal, the company needed a public face that matched the business: a clean, elevated site with the fleet, the services, and the aircraft brokerage side. We built it as a fast static site with real photography, a working contact form, and search optimization for the local aircraft management market. It's the front door; the portal lives behind it.
Step two: the owner portal, deliberately small
V1 was locked in a single call. Two features:
- Trip request. An owner logs in from their phone, picks their aircraft, and requests a trip: one-way, round-trip, or multi-leg. Each leg has a departure, an arrival, a date, and a time (or "flexible"). Passengers come from a saved list per owner, with per-leg on and off toggles. Extras are simple checkboxes: rental car, catering, baggage, pets, special requests.
- Calendar. The owner sees the full schedule for their aircraft, not just their own trips, so they know when it's blocked for another owner or in maintenance.
Every request emails the operations team with Confirm and Decline links that work from a phone. Confirm, and the owner automatically gets a decision email with a clean itinerary. Decline, and they get that too. Nobody has to remember to notify anyone.
The details that make a portal feel professional
"Simple" and "cheap-looking" are different things. A few of the pieces that separate this from a web form:
- Real airport search. Owners type a city, airport name, or code and get instant matches from a complete global airport dataset. For legs that start at a street address rather than an airport, the form offers real address suggestions and refuses to submit a leg without a house number, so the operator never has to chase down "which house?"
- Owner and aircraft boundaries enforced in the data layer. One owner can have several aircraft; one aircraft can have several authorized requesters. An owner or their delegate (an executive assistant, say) only ever sees their own aircraft. This isn't a display filter; it's enforced by the database.
- Roles for the whole operation. Admin, owner, owner delegate, pilot, maintenance, accountant. Admins can even have specific tails hidden from them, and the system refuses any change that would leave an aircraft with no admin who can see it.
- Change requests. Trips get a reference number. When an owner changes a trip, the new request links to the one it replaces, so the team never wonders which version is current.
- Reminders that run themselves. An hourly job watches for trips still awaiting a decision and emails the team with the real distance to departure ("departs in 2 days"), replacing the manual 48-hour notify step.
- Passengers and passports, done carefully. Owners maintain passenger profiles with the manifest data flight operations actually needs, and can upload passport documents. Those documents live in encrypted storage, are served only through short-lived signed links, are scoped to the right owner, and every view and download is logged. No passport data ever appears in an email or a log.
- Pilot post-flight logging on a phone. A pilot logs in, sees their assigned trips, and after landing enters times, fuel burn, and landings on a screen built for a cockpit, not a desktop. The next layer pulls hours and landings automatically from flight tracking data so the pilot's only manual entry is fuel.
Built as a product, not a one-off
Under the hood this is two things. The engine is multi-tenant operations software: accounts, roles, trips, calendars, passengers, documents, notifications, with every table scoped to an operator so no data can cross between companies. The owner portal is a white-label front end on top of it, with branding isolated in a config layer so it can be re-skinned and dropped onto another operator's website.
That matters for the client in two ways. It means their system is built on a proper foundation rather than a pile of scripts, and it means the next operator who needs the same thing gets it faster and cheaper, which keeps us honest about building it well the first time.
Mobile first, and native when it's warranted
Owners request trips from their phones and pilots log flights from the cockpit, so the portal was designed phone-first: fast, thumb-friendly, and installable to the home screen so it behaves like an app. The management side, where the operator lives all day, is a full desktop experience.
When a project genuinely needs a native app (push notifications, offline use, App Store presence), we build that too. We've shipped a native iOS app of our own through Apple's TestFlight and App Store pipeline, so we know what that road looks like and, just as importantly, when a mobile-first web app is the smarter choice.
What it's replacing, and the roadmap
The layered plan, in the operator's own sequencing:
| Layer | What it does | Status |
|---|---|---|
| 1. Owner portal | Trip requests, calendar, decision emails | Live |
| 2. Accounts and operations console | Owner logins, fleet calendar, passengers and documents, pilot logs, reminders | Live |
| 3. Flight tracking data | Auto-pull hours and landings from ADS-B so pilots only enter fuel | Next |
| 4. Maintenance tracking | Push flight data into the maintenance system so inspection alerts fire automatically | Planned |
| 5. FBO and ground transport | Notify FBOs and book rental cars from the trip itself | Planned |
| 6. Accounting | Owner billing and reports | Planned |
Each layer is roughly a week of work. The business case is straightforward: the legacy platform costs about $950 a month and still requires the double entry described above. The custom system runs on a few dollars of hosting, and every layer removes a manual step rather than adding a login.
What we'd tell another owner considering a custom build
- Lock a tiny V1 and ship it. Two features in production beat twelve features in a document. Real users surface the real priorities.
- Own your data first. Once your trips, customers, and schedules live in a system you control, every integration becomes optional instead of existential.
- Design for the phone the person actually holds. Owners and field staff use phones; managers use laptops. Build both, but don't make one pretend to be the other.
- Treat sensitive data as a workstream, not a checkbox. Encryption, signed links, scoped access, and audit logs were in scope from the day passports entered the picture.
- Plug into the tools worth keeping. The client's maintenance tracking system is the industry standard. We're not replacing it; we're feeding it.
If your business runs on software you pay for and resent, or on a process that only exists in your head and a group text, that's exactly the conversation our free audit is for. We'll tell you honestly whether the answer is an integration, an automation, or a build.