Ten questions to ask before choosing flight school software

Every product looks good in a demo: the scheduling calendar is colourful, the reports are tidy, the sales team is friendly. The problem is that how a product behaves in daily operation never shows in a demo. The ten questions below bring the points that only surface in use to the table before you buy.

1. Can we define the syllabus ourselves?

Some products ship the syllabus as a fixed template; adding an exercise, changing a duration or setting a repeat rule means writing to the vendor. When your syllabus changes, and it will, that dependency costs weeks every time. In the demo, define an exercise group, an exercise, its duration and a special-row flag yourself.

2. Is currency checked at planning time or at report time?

A flight flown on an expired medical cannot be corrected afterwards. Does the product block it on the planning screen, or show it on a month-end report? In the demo, set up an expired document and try to schedule that person. If it warns and lets you through, there is no check.

3. Is the completed flight the updated plan, or a separate record?

When the plan lives in one place and the completed flight in another, the difference can only be found by hand. Look for a structure where actual off-block and on-block times go into the plan’s own row, and the duration posts itself to the student, the exercise and the aircraft.

4. Is the logbook derived from the schedule?

If the student’s logbook is filled in separately, it will eventually disagree with the scheduling records. Check that logbook rows are generated from the completed flight and that the column layout matches the official logbook.

5. How will our existing data be migrated, and by whom?

“You can import from Excel” usually means “you do the work”. Ask in writing who will migrate the student list, historic hours, document dates and fleet data, in what format and how long it will take. Is migration included in the price or extra?

6. What drives the price?

Per-user pricing makes every new student a cost; the bill grows with the school and the team avoids creating accounts. Per-module pricing grows as needs appear. A flat price by fleet size or school size is the only model you can plan around.

7. Where is the data stored, and who can access it?

Student identity details, medical expiry dates and payment records are personal data. Ask which country the server is in, how often backups run, and under what conditions vendor staff can access your data. Do not accept a verbal answer.

8. If we leave, how do we get our data back?

The format and timeframe for handing data back at the end of the contract should be written down from the start. Leaving a product that cannot answer this clearly costs more than joining it.

9. Do instructors and students see their own screens?

A product with only a management screen will not be used by the team; instructors keep asking on WhatsApp and students keep phoning. An instructor seeing the day’s flights and a student seeing remaining hours and balance in their own panel is what makes the system the single source of truth.

10. Who is support, and how fast do they respond?

When something breaks at 7 a.m. on a flying day, who do you write to and when will you hear back? “Support by email” is not an answer; ask for a response-time commitment and whether support is available in your language.

How to run the demo

Send these ten questions before the demo and ask for written answers, not meeting answers. In the demo itself, replay one day of your own school: enter the fleet, schedule a student, complete the flight, open their logbook. Whether the product fits your operation becomes clear in that half hour.