What a gliding club actually needs from flying-day software

One flight, five people who need it

A launch at a gliding club is a small event with a long tail. The launch point marshal wants the flying list. The winch driver or tug pilot wants to know who is next. The instructor wants the flight in the student's training record. The aircraft team wants the airframe hours. The treasurer wants the launch fee and the soaring time on the member's account at the end of the month.

All of that comes from one line in the log: who flew, in what, launched how, at what time, landed when. If that line is right, everything downstream is easy. If it is wrong, or written on a clipboard that stays in the bus, five people rebuild it separately and get five different answers.

This guide is about what club software has to do with that one record. It is not a product review. GlideHQ, our own gliding club app, is in development and not available to use, and we say more about that at the end.

What clubs run on today

We read the pages of two UK clubs that publish details of their club system, plus one newer tool.

RAF Cranwell Gliding Club and Stratford on Avon Gliding Club both use Glidex, which Stratford describes as its flight logging and club administration software, and names John Dickinson as its author. Cranwell's page lists the modules: flying list, flight logging, visitor event flight logging, and password-protected member, bursar and administration modules.

The flying list entry on that page is worth looking at closely, because it is a good picture of what the launch point needs to know before anyone flies. A member adds themselves by membership number, states whether they need instruction or a check flight, lists the solo glider types they want, picks the duties they will do that day (glider retrieve, cable retrieve, log keeper, launch point marshal, winch driver, tug pilot, duty instructor), and sees their account balance. All of that before the first launch.

GliderOps, a newer tool written by someone who runs operations at a US soaring club, describes the same day from three seats: the duty officer's Saturday with dispatch, launch log and sign-ins on one screen; the treasurer's month where flights become charges and charges become invoices; and the maintenance officer's calendar of annuals, squawks and engine hours.

Different products, same shape. The flying list feeds the launch log, the launch log feeds the training record, the aircraft record and the bill.

The flight record and its states

A flight is not one event. It moves through states, and the software needs to know which state it is in.

Queued: the pilot is on the flying list and has been told they are next. Launched: the cable or tug has gone. Airborne: the glider is up, and the log keeper is watching the time. Landed: the glider is back, with a landing time. Confirmed: someone with authority has checked the line and it now counts for training, hours and money.

Most clipboard systems record launch and landing and skip the rest. That is fine until the treasurer bills a flight that was later corrected, or an instructor signs off an exercise on a flight that was logged against the wrong student.

The confirmation step is the one to insist on. Nothing should reach a training record or a member's account until a person has said the line is right.

Training records need the flight, not a note

Instructors keep training records. In many clubs those are paper cards or a spreadsheet kept by the CFI. The flight log and the training record are updated separately, so they disagree.

Software helps when the instructor records the lesson and any sign-off against the actual flight. That gives the club one answer to "how many launches has this student done on type", and it gives the student a record they can see.

Two things to be clear about. A training record informs the people authorised to decide what a pilot may do. It does not make the decision. And the software's job is to hold the record, not to certify anyone.

Aircraft records: usage, inspections, defects

The aircraft team needs hours and launches per airframe, the dates of inspections, the documents that go with each aircraft, and every defect reported and cleared. Gliders, tugs, touring motor gliders and the winch all need this, and they each have different maintenance cycles.

The mistake to avoid is treating a software status as airworthiness. A green tick in a system is a record that someone has done the club's return-to-service process. It is not the process. The club's authorised person still signs the aircraft off.

Money follows the confirmed flight

Club accounts at most gliding clubs are a combination of launch fees, soaring time, membership and whatever else the tariff says. The treasurer's job is easiest when every charge points back to a confirmed flight, because a query from a member can be answered by showing the line.

A tariff in software should be a rule the club sets, not a number the treasurer types each month. Change the winch launch fee once and every flight after that date picks it up. Keep club charges separate from anything the club pays for the software itself.

Questions to ask any gliding club system

Put these questions to Glidex, GliderOps, a spreadsheet someone built, or a product still in development. They separate a flying-day system from a general club database.

1. Does the flying list capture instruction needed, check flight needed, solo types and duties, in the way Cranwell's list does?
2. Can the launch point run the log on a phone or tablet outdoors, in glare, with cold hands?
3. Does a flight move through states, with a confirmation step before it counts?
4. Can an instructor record a lesson against a specific flight?
5. Do aircraft records hold usage, inspections, documents and defects per airframe, including tugs and motor gliders?
6. Do charges point back to a confirmed flight, and can the tariff be changed by date?
7. Can members see their own flights, training progress and account?
8. What happens on a day with no signal at the launch point?
9. Who owns the data, and can the club export it?

The eighth question is the one clubs forget. Many airfields have poor mobile coverage at the far end of the field. A system that assumes a connection is a system that gets abandoned by August.

Where GlideHQ fits

GlideHQ is still in development, so clubs cannot use it yet, and no public launch date has been announced. The build centres on the confirmed flight record described above, following a flight from the queue through launch, airborne and landed states to confirmation, with a live board and flight history using that shared record. Training records, aircraft records for gliders, tugs, touring motor gliders and equipment, and club accounts based on confirmed flights are all part of the intended scope. If you want to talk about your club's requirements while it is being built, the contact page is the place.

What to do in the meantime

If your club is on a clipboard and a spreadsheet, the highest-value change is not software. It is agreeing who confirms the log at the end of each flying day and doing it before anyone goes home. One person, one pass through the day's lines, every flying day.

Once that habit exists, moving to any system is straightforward, because the club already has a clean record to import. Without it, software will inherit the same disagreements the clipboard had, only faster.

The apps that are available now for rowing, sailing and paddling clubs are listed at sports clubs.