Modern operations software for flying clubs and flight schools. Aircraft scheduling, member management, fleet visibility. Built from zero as a production SaaS.
The Problem
Most flight schools and flying clubs operate with a patchwork of Excel files, WhatsApp groups, and aging legacy software. Scheduling a training flight means calling an instructor, checking a whiteboard, and hoping nobody else already took the slot. It's inefficient, error-prone, and genuinely risky.
Existing software options are either built for large commercial operators (expensive, over-engineered), or outdated systems with no mobile support and painful UX. Small clubs, the backbone of general aviation, have been underserved for decades.
Manual booking systems lead to double-bookings. No central source of truth means instructors and students show up for the same aircraft at the same time.
Membership status, certifications, and access permissions tracked across spreadsheets. No easy way to know who can fly which aircraft, or whether someone's medical is current.
Aircraft maintenance schedules managed manually. Squawks ignored. No audit trail for airworthiness decisions. In aviation, this is a safety issue, not just an operations problem.
Instructors and club managers work from phones and tablets. Legacy systems require desktop browsers and haven't been updated in years.
The Solution
OmniFlyer is a multi-tenant SaaS platform designed from the ground up for flight schools and flying clubs. Club administrators get a single dashboard to manage aircraft, schedule bookings, and oversee their operation. Members get a clean interface to view availability and book flights.
The architecture is built around real aviation workflows. Booking conflict detection happens at the database level, not just the UI. Role-based access ensures the right people see the right information. And the entire system is designed to work as well on a phone as on a desktop.
Rather than trying to replicate enterprise aviation software at a smaller scale, I started from the actual problems small clubs face: simple scheduling, reliable access control, and a system people will actually use.
Product
Under the Hood
Building OmniFlyer meant making real architectural decisions, not just wiring together components. Here's what the system does technically and why those choices matter.
Each organization is fully isolated at the data layer. A club's bookings, members, and aircraft are never visible to other tenants. Designed to scale to hundreds of organizations without schema changes.
Booking conflicts are prevented at the database level with Supabase row-level security, not just the UI. A member cannot double-book an aircraft even with a race condition. This is a hard requirement for aviation safety.
Three distinct roles (Admin, Member, Instructor) with permission enforcement via Supabase row-level security policies. Admins manage the organization; members can only access their own bookings and available aircraft.
PostgreSQL database with real-time subscriptions, built-in auth, and row-level security. The relational model maps cleanly to aviation domain objects (organizations, aircraft, bookings). Auth handles multi-provider sign-in with session management built in.
Next.js 15 with React for the web dashboard, optimized for both desktop admin workflows and mobile member access. Booking calendar view with scroll-based time navigation and availability visualization.
Every booking creation, modification, and cancellation is logged with timestamp and user identity. Aviation operations require an audit trail. This is built in from day one, not bolted on.
New members join organizations via invitation codes rather than admin-created accounts. Reduces admin burden, works for clubs of any size, and keeps member data under organizational control.
Full localization built in from the start. Aviation clubs need software in their own language. Built using a custom i18n layer on top of React, with easy extension for additional locales.
Deployed via Firebase Hosting with a custom domain. Cloud Functions handle server-side operations including transactional email via Brevo. No servers to manage.
My Role
OmniFlyer is my own product. There is no team. I conceived it, designed it, built it, and brought it to market. That means making every decision, from the data model to the pricing page copy, with no one to defer to.
Building a product this way forces a kind of discipline that's hard to replicate in a team setting. Every hour spent on a feature is an hour not spent on something else. Every architecture decision is permanent until it isn't. You learn very quickly what matters.
Outcome
OmniFlyer is currently in early access, onboarding flight schools and flying clubs. The core booking, scheduling, and member management functionality is complete and running in production.
The product has gone through multiple rounds of customer feedback, with direct conversations with club managers and flight school operators. Every major design decision (the invitation system, the role model, the calendar layout) came from talking to real users.
The codebase is built to scale. Adding new organizations takes seconds. The security model supports hundreds of clubs without any architectural changes. The path to growth is clear.
I built OmniFlyer from zero: product, architecture, frontend, backend, infra, and go-to-market. That's the same capability I bring to client work. Book a call and let's talk about what you're building.
Reach me at hello@skywaylabs.io