Skip to content
← All work

SkyLog

In production

SkyLog 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

1 / 4

Stack

  • Flask
  • PostgreSQL
  • Docker
  • Jinja2 templates