Why a volunteer fire brigade needs a drone system, not just a drone

The story is familiar across Polish volunteer fire brigades (OSP). The municipality or a sponsor pays for a drone. There is a handover, a photo in front of the station, a social media post. Two people get their pilot certificates. The drone goes out on its first search and performs brilliantly.

Then a year passes. And it turns out the unit bought equipment, but nobody designed what happens around it.

A drone is equipment. Flying is a process

No fire brigade treats a fire engine like an ordinary vehicle. The engine has a work log, inspections, assigned drivers with the right licences and someone responsible for all of it.

A drone is in the same position, it is just rarely described that way. It is an aircraft with its own records, batteries that wear out and pilots whose certificates expire. There is one difference: the engine has had its procedures for decades, while the drone arrived with a user manual and nothing else.

Four places where it falls apart

Logs stay on the memory card. Every flight is recorded by the controller. Route, time, altitude, battery state. It is ready-made documentation of the operation that nobody downloads. After a few months the card fills up, someone formats it and the unit’s flight history is gone.

The flight logbook is a paper notebook, or does not exist. If it exists, one person keeps it, from memory, the day after the operation. Times are approximate, locations described in words. When that person goes on holiday, the entries stop.

Nobody knows what condition the batteries are in. How many cycles each one has. Which one has recently been losing voltage faster. Which one should already be retired. That knowledge lives in one pilot’s head, or nowhere at all. A weak battery makes itself known at the worst moment: in the air, over a forest, at night.

Certificate expiry dates are remembered by the person they belong to. Or not remembered at all. The commander learns about an expired certificate when a pilot needs to be sent out.

None of this is negligence. It is the natural result of a unit receiving a device without receiving a way of working with it.

When it surfaces

Day to day, the lack of a process does not hurt. The drone flies, the photos are there, the missing person is found. The problem appears when someone from outside asks to see the records.

• After an incident. The drone crashed, damaged property or came dangerously close to something. The first questions are: who was flying, with what certificates, what condition was the equipment in, how did the flight go.
• With an insurance claim. The insurer will ask for flight documentation and the aircraft’s history.
• When accounting for funding. The municipality that paid for the drone has every right to ask how much it actually flew and what it was used for.
• During an inspection. EU drone rules (Regulation 2019/947) make the operator responsible for who flies, with what and under which rules. In the specific category they explicitly require keeping and retaining records of operations, personnel and maintenance. A separate post will cover these obligations in detail.

In each of these situations “it’s on a card somewhere” is a weak answer. “Here is the report” closes the matter in five minutes.

What a system should do

This is not about another program to fill in late at night. It is about a tool that takes work off people. A good system for a unit with a drone should:

• build the flight logbook by itself, from the logs recorded by the controller, with no retyping,
• keep a register of drones and track battery condition: cycle count and health,
• watch the deadlines: pilot certificates, insurance, inspections,
• show what is happening in the air, so the incident commander sees the drone on a map without standing behind the pilot,
• work without installation, in a browser, on hardware the unit already has,
• hand over the data in one click when a report or a summary for an inspection is needed.

A spreadsheet covers the first point for a month. Then the notebook comes back.

What this looks like in FLAARE

This is exactly what FLAARE was built for. It is a system for an organisation, not an app for a single pilot. It runs in a browser.

After a flight it is enough to upload the log file from the DJI controller, and the flight logbook entry creates itself: with the route, times, altitudes and the drone’s serial number. From the same logs the system counts battery cycles and shows which battery is weakening faster than the others. Pilot certificates have expiry dates, and upcoming deadlines appear as notifications. During operations the organisation’s drones are visible live on the operations map. The entire logbook can be exported to a file.

A drone is bought once. The process around it runs on every flight. It should not depend on one person’s memory.