Booking and the schedule

Conflict rejection, not conflict warning: Overlap checks run in the database as the reservation is committed. Two people booking the same airframe in the same second cannot both win. A browser-side check that shows a dismissible dialog is not the same guarantee, and the difference only shows up on the busy Saturday when it matters.
Recurring booking series: A weekly slot is created once. Every occurrence is conflict-checked individually, so one clash in week six does not quietly displace another member. Which roles may create series is configurable.
Per-aircraft booking permissions: Booking rights are granted by role and can differ per airframe, so a member who is not checked out on type does not see it as bookable. Flight schools invert the default so students request and dispatch confirms.
Live METAR: Current conditions for your base airport render beside the schedule. It is a convenience, not a briefing tool, and we are not going to pretend otherwise.
Booking visibility control: Whether members can open one another's bookings is an organization setting. Set it off and other members' reservations appear as busy blocks only. Your own booking is always fully visible to you.

Fleet and maintenance

Grounding that propagates: Marking an aircraft unserviceable removes it from the booking calendar immediately and makes its status visible to everyone holding a future reservation against it.
Squawks with photographs: Defects are raised from a phone at the aircraft, with an image attached, and tracked through to administrator sign-off. The defect history stays attached to the airframe rather than scattered across chat threads.
Inspection monitoring: Inspection dates and hour-based intervals are tracked against each aircraft, counted down against the current meter reading rather than against a figure someone typed in last quarter.
Journey log capture: Closing a flight records the tach and Hobbs readings and updates the airframe total at that moment, producing a digital record per flight instead of a transcription exercise later.

Access, roles, and data isolation

Tenant isolation enforced in the database: Every read and write is scoped to your organization by row-level security rather than by application code remembering to filter. A bug in a screen cannot leak another organization's aircraft or members, because the database refuses the query.
Role-based permissions: Roles differ by organization type — members and committee for clubs, students, instructors, and dispatch for schools — and govern who can book, amend, ground an aircraft, or sign off a defect.
Audit trail: Bookings, amendments, groundings, and defect sign-offs are attributed and timestamped, which turns most disputes into a lookup.
Invitation-based onboarding: Members join by emailed invitation or a club join code. Nothing to install: the application runs in the browser on phones, tablets, and desktops.

Not built yet

Listing these is more useful than burying them. None of the following exists in version 1:

Member or student invoicing, and any card or ACH payment processing
Syllabus and training-progress records for Part 141 or ATO operations
Document management for member licences and medical certificates
Accounting integrations, and automatic engine-data import from avionics

If one of these is your deciding factor, say so in the form below and we will tell you honestly where it sits — or that you should look elsewhere.

OmniFlyer has been shut down

We are no longer onboarding flying clubs or flight schools. If you have a question about OmniFlyer or a software problem you want solved, you can find us at Skyway Labs or email hello@skywaylabs.io.

Visit Skyway Labs → Email us