At a Glance
The Problem
A Part 135 operator is a charter or on-demand air carrier: air taxis, medical transport, corporate charter. Unlike a major airline it runs lean, often with a handful of aircraft and a chief pilot who is also the safety officer, the scheduler, and frequently still flying the line.
That operator is running four separate systems. Safety reporting sits in one place, usually a spreadsheet or a paper form. Flight operations and crew scheduling sit in another. FBO and ground handling in a third. Aircraft maintenance and airworthiness tracking in a fourth. None of them talk to each other, so the same flight is entered four times and the safety picture is only ever assembled after something has already gone wrong.
Then the FAA set a date. Part 135 operators must have a formal Safety Management System in place by May 2027. An SMS is not a document you file once. It is a continuous loop of hazard identification, risk assessment, mitigation and assurance, and every part of it has to be evidenced. For an operator whose safety data lives in a filing cabinet, that is not a software upgrade. It is a change to how the business runs.
Why This Was Hard to Deliver
Aviation software carries constraints most SaaS does not, and each one shapes the delivery plan rather than just the backlog.
The deadline is statutory, not commercial. Most software dates move when scope pressure arrives. This one cannot. An operator that is not compliant in May 2027 does not have a delayed feature, it has a grounded certificate. That inverts the usual negotiation: scope flexes, the date does not.
The users are professionals with no tolerance for friction. A pilot filing a safety report is doing it between duty periods, often on a phone, often tired, and under a regulatory obligation. A confusing form does not generate a support ticket. It generates an unreported hazard, which is precisely the outcome the system exists to prevent.
The domain experts are in the room. The product was built alongside a B747 captain, a Part 135 chief pilot, a CFI rated on 62 aircraft types and an aviation attorney. That is an enormous asset and a delivery problem at once: deep domain conviction has to become buildable, sequenced, testable scope without flattening the expertise that makes the product credible in the first place.
How I Approached Delivery
- Sequenced against the regulation, not around it. SMS capability first, because that is the part carrying a legal date. Flight ops, FBO and maintenance consolidate around that spine. An operator can arrive for compliance and grow into the rest, rather than needing all four before any of it is useful.
- Treated security architecture as day-one scope. Enterprise authentication through WorkOS, edge protection and delivery through Cloudflare, error and performance monitoring through Sentry from the first release rather than retrofitted before a security review. For buyers who ask about data handling on the first call, this is scope, not polish.
- Converted domain expertise into specifications. Working sessions with the aviation principals turned regulatory requirement and operational reality into BRDs, user stories and acceptance criteria an engineering team can build against without holding a type rating.
- Ran a written-first cadence across time zones. Decisions, risks and status recorded in the tracker rather than held in meeting recall, so operators, pilots and engineers work from one source and progress never waits on an overlap window.
- Kept the evidence trail in scope throughout. An SMS is only worth having if it can be demonstrated to a regulator. Auditability was treated as a functional requirement from the start, not a reporting feature added at the end.
What the Platform Does
Safety Management System. Hazard reporting, risk assessment and the assurance loop the May 2027 rule requires, with the audit trail that makes it defensible.
Flight Operations. Scheduling, crew and trip management running on the same data as the safety record, so a risk raised on one flight is visible against the next.
FBO Management. Ground handling and fixed-base operations consolidated into the same platform rather than run as a separate book.
Aircraft Maintenance. Airworthiness and maintenance tracking connected to the operational picture instead of running parallel to it.
PIC Score. A pilot-in-command score built from more than 500 analyzed data points, giving crew and operators an objective read rather than an impression.
Tools & Technologies
Frontend
Platform & Data
Identity & Payments
Observability
Domain
The Stack, and Why
React and MUI for an interface used both on the ground and in the air, where consistency matters more than novelty. PlanetScale for a relational model that has to stay coherent across four previously separate domains. Cloudflare for edge delivery and protection to an internationally distributed user base. WorkOS for enterprise authentication, because operators arrive expecting SSO. Stripe for billing. Sentry for observability from day one rather than after the first incident.
Outcome
One platform in place of four systems, aimed at a compliance deadline every Part 135 operator in the United States has to meet, and used by professional flight crew flying internationally across a route network spanning 132 countries.
The product is live at planeconnection.com.