SkyLog
In productionSkyLog replaced the paper flight logbook pilots and administrators at Ghana Air Force Headquarters used to record every flight by hand. It computes flight time automatically across day, night, instrument, instructional, and simulator categories, and it was still receiving feature work in January 2026, after Ron's national service posting there had ended.
- Role
- Sole author
- Period
- 2025 to present
- Status note
- Still running inside the Air Force network, still receiving feature requests.
The problem
Every flight at the unit was logged by hand in a paper logbook: hours totalled with a calculator, categorised by eye into day, night, instrument, instructional, and simulator time, and verified whenever someone had time to check the arithmetic. Official reports meant retyping the totals from the paper record.
The constraint
The system has to run inside a closed military network with no external access, and it has to be operated day to day by staff who are not engineers. There is no help desk to call and no internet connection to lean on for a fix.
Architecture
A Flask application over PostgreSQL, 16 models and 74 routes, with 54 server-rendered templates. Flight time is computed automatically from logged flight segments across the five categories the unit tracks, and an admin verification workflow replaces the manual arithmetic check. Reports render in a print-formatted layout that matches the paper form's official layout, so a printed SkyLog report looks like the document it replaced.
It ships as a Docker container with a set of operator batch scripts, install, start, stop, status, and backup, so someone with no development background can run and maintain it unaided inside the closed network.
Decisions, and what they cost
Copy the paper form's structure before improving it
The templates and the report layout deliberately mirror the structure of the paper logbook rather than redesigning it around what a web form makes easy. Pilots trusted the system because it looked like their logbook, not because it looked like new software. Improving the workflow came after that trust was established, not before it.
Operator scripts instead of a deployment runbook
Because nobody at the unit maintains software for a living, the install, start, stop, status, and backup steps are batch scripts rather than documented commands someone has to remember and type correctly under pressure. The backup script in particular exists because a lost logbook of record is not something a unit can shrug off.
What didn't work
Instrument rating types the initial design didn't anticipate
The original category set didn't cover every instrument rating type the unit actually uses. Ghana Air Force-specific rating types, WHITE and GREEN, and multi-select approach types had to be added after the fact, in January 2026, well after the initial build and after Ron's national service posting had ended. That gap, and the fact that it got fixed rather than left, is the clearest evidence anyone has that the system is genuinely relied on rather than merely installed.
More
The design lesson, in his words
When you replace a paper process, copy its structure before you improve it. Pilots trusted the system because it looked like their logbook.
The numbers
- PostgreSQL models
- 16Counted. repository
- Flask routes
- 74Counted. repository
- templates
- 54Counted. repository
- commits
- 58Counted. git log
Screenshots




Stack
- Flask
- PostgreSQL
- Docker
- Jinja2 templates