I am the person behind AeroLine Digital and EFB Logbook. I am also a father to two beautiful children, who inspire far more of this work than they probably realise. A lot of EFB Logbook has been built during long nights of coding, usually once the rest of the house has gone quiet.

That means I write the code, make the product decisions, read the feedback, test the releases and occasionally stare at a problem for far longer than I would care to admit. It is demanding, especially when it has to fit around family life, but building something I believe in—and showing my children what can grow from an idea—is a huge part of why I keep going.

Until now, most of that work has only been visible at the very end: an app update, a short release note or a new button that was not there the day before. That misses the more interesting part. Features rarely arrive fully formed. They start as an idea, change after testing and quite often expose a completely different problem that needs solving first.

The Logbook is where I want to share that journey properly.

What I want this to be

This will not be a stream of polished announcements pretending everything went perfectly. I want to write about why EFB Logbook works the way it does, what I have learned while building it and the compromises behind decisions that may look simple from the outside.

There is plenty to talk about. EFB Logbook now spans Android, iOS and Windows. The Windows app can record simulator flights and build detailed local debriefs. Selected flight information can then appear on mobile, while the raw telemetry and full Windows debrief stay on the PC. That apparently simple sentence contains months of questions about privacy, cloud cost, sign-in, compatibility and how much data is actually useful away from the simulator.

I want this to be a genuine look behind EFB Logbook: the ideas that work, the ones that change along the way and the lessons that only appear once something is placed in front of real people.

The honest parts matter too

Building software on your own is rewarding, but it can also be messy. A feature can look brilliant in an emulator and feel completely wrong on a real device. A map colour that follows the brand perfectly can be difficult to read. A sensible security change can expose an old assumption elsewhere. Sometimes the right answer is to rebuild something; sometimes it is to stop adding things and make the existing experience clearer.

I think those decisions are worth sharing. They give more context than a changelog ever could, and they keep me accountable for the choices I make.

What comes next

Some entries will look back at features that already exist. Others will follow work in progress, including the continued development of Windows, better ways to review recorded flights and the careful work needed to make EFB AI genuinely useful rather than a label attached to the app.

I also want to write about the less glamorous parts: launching on different stores, keeping infrastructure affordable, designing for accessibility and working out when a feature has earned the space it occupies.

This is entry one. There is a lot more in the logbook.