Drone Operations Software Case Study (Dronelog)

This drone operations software case covers my work for Dronelog, a platform for drone operators. Software like this has one core job: making it easy to prove who flew which drone, where, and under which authorization. Below I walk through the brief, the decisions it forced, and what you can reuse if you're planning a platform for a regulated niche anywhere in Europe.

[PLACEHOLDER: Confirm written permission from Dronelog for name, logo and any quote, and confirm the description above. Otherwise anonymize the case and change title and slug.]

The short answer: the project at a glance

[PLACEHOLDER: 2-3 sentences in your own words on the problem before the project, what was built and what changed for the users.]

This post is part of a series on projects I've worked on. Read more about product choices and priorities in from idea to SaaS: choices and priorities.

What drone operators need from their software

Before I build anything for an industry, I need to understand the rules it works under. In the EU, drones fall under common rules that EASA splits into three operating categories: open (low risk), specific (medium risk) and certified (high risk). Open category flights stay below 120 meters, and the subcategory depends on how close the drone gets to people.

Anything beyond those limits, such as flying beyond visual line of sight, above 120 meters or with a drone over 25 kg, belongs in the specific category. There, the operator needs an authorization from the national aviation authority or must submit a declaration under a standard scenario, and an operations manual is required, as EASA's guidance on the specific category sets out. On top of that come national procedures. In Denmark, for example, any organization flying commercially must register as a drone operator with the Danish transport authority (page in Danish) and display its operator number on every drone it flies.

Translated into software, that usually means the platform has to keep track of:

• remote pilots and their certificates and training
• aircraft, their class, operator markings and maintenance
• authorizations and declarations, and the limits they set
• flights: who, what, where, when and in which category
• incidents and deviations, so they can be followed up

That's my reading of the rules as a developer, not legal advice. Which requirements apply to a given operator depends on the type of operation and should be confirmed with the national authority or an aviation consultant.

[PLACEHOLDER: Which of these needs the Dronelog platform covers, and which it deliberately leaves out.]

The brief: what Dronelog needed

When I start on a platform for a niche, I spend the first stretch understanding the workflow, not sketching screens. What happens from the moment a job comes in until the drone is packed away again, and where do double entry and documentation gaps creep in?

[PLACEHOLDER: Starting point and goal. How did users handle this before (spreadsheets, paper logbooks, an older system), and what did the first version have to do?]

[PLACEHOLDER: How you got involved and what you were responsible for. First-person prose.]

Four decisions that shape drone operations software

These four choices come up in almost every platform for drone operators. For each one, here's why it matters and what was chosen for Dronelog.

Rules as data, not code

Drone rules change. Declarations under the European standard scenarios, for instance, have only been possible since 1 January 2024, according to EASA. If categories, altitude limits and pilot requirements are hard-coded, every rule change needs a developer. Stored as data, they can be updated by an admin, and an old flight can still be shown against the rules that applied at the time.

[PLACEHOLDER: How rules and requirements were handled in Dronelog, and whether the approach held up.]

Roles and permissions

An operator is rarely one person. There's usually someone responsible for operations, pilots who fly, and perhaps a client who needs to see the records. Who can create flights, who can approve them, and who can only read? This is much easier to design up front than to retrofit, and I've written a guide to SaaS roles and permissions on exactly that.

[PLACEHOLDER: Which roles the platform has, and how access is split between organizations.]

Built for the field

Records are created at the take-off site, not at a desk. If a pilot needs five minutes on a phone in the wind to log a flight, it gets done later or not at all. That means large tap targets, few required fields, sensible defaults and a plan for what happens when the signal drops.

[PLACEHOLDER: Is the platform used on mobile in the field, offline too, and what worked?]

Records you can hand over

The point of the records is to show them to a client, an insurer or an authority. So the data has to come out in a format other people can read, such as a report per flight or per period. It also has to be trustworthy: who changed what, and when.

[PLACEHOLDER: Reports, exports or integrations in Dronelog, if relevant.]

Results and what I'd do differently

I judge a platform like this on one thing: do people use it every day? A logbook that pilots skip is worthless, however many features it has.

[PLACEHOLDER: What was delivered, and when did it go into use?]

[PLACEHOLDER: Measurable results Dronelog has approved for publication, e.g. number of users, time saved or fewer documentation errors. No numbers without approval.]

[PLACEHOLDER: Optional quote from Dronelog with name and title, only with written permission.]

[PLACEHOLDER: One or two things you would do differently today, and why. Write it as prose, including what went wrong along the way.]

Lessons for building niche SaaS in Europe

Dronelog has a lot in common with other platforms for regulated industries, from electrical contractors to transport and healthcare. A few lessons carry over:

1. Start with the workflow, not the feature list. Follow one user through a complete job before deciding what the system should do.
2. Keep the first version narrow: one user type and one workflow that works end to end. That's the thinking behind my week-by-week MVP development process.
3. Treat rules, limits and requirements as data so they can change without a new release.
4. Keep a domain expert close. A pilot or operations lead who tests every week catches more problems than any specification.

The EU angle is worth planning for early. Because the operating categories are common across member states, the core of a platform built for Danish operators should largely fit operators in Germany or the Netherlands too. What differs is the national layer: registration procedures, language, local zones with their own restrictions and how you deal with each authority. If expansion is on the table, make those parts configurable from day one rather than hard-coding one country.

For another project from this series, see the case on building features for a growing employee platform.

When custom software is the wrong call

If an existing logbook or fleet management tool covers most of what you need, buying it is almost always cheaper. Custom software pays off when the workflow is your competitive edge, when off-the-shelf tools force workarounds every day, or when the platform itself is the product you plan to sell.

And if the software has to control the drone itself, process sensor data in real time or form part of a certified aviation system, that's a different specialty from mine. I build web platforms and SaaS, not firmware or flight safety systems, and you'll be better served by a specialist in that field.

Next steps

If you have an idea for software in a niche, the first step is describing the workflow and who will use it. You don't need a full specification. Larger projects with me start with a paid, fixed-price discovery phase where the scope is defined and priced, and you own the code from day one.

You can read how a project with me runs from first call to launch, or see what I offer for SaaS and niche platform development.

Frequently asked questions

How much does custom drone operations software cost?+

It depends on scope, and a serious estimate needs a defined scope first. The biggest cost drivers are the number of user types, how much has to work in the field, integrations such as maps or weather data, and how much reporting is required. That's why I start larger projects with a paid, fixed-price discovery phase, so you get a fixed price you can actually decide on.

Can you take over an existing platform instead of starting from scratch?+

Often, yes. I maintain and extend existing systems, particularly Laravel and JavaScript projects, and taking over is usually cheaper than a rewrite if the codebase is in reasonable shape. I start by reviewing the code, hosting and documentation, so you know what you're inheriting before you commit to bigger changes.

Does drone software need to work offline?+

It depends on where your pilots fly. If they often work in areas with poor coverage, being able to save data on the phone and sync later is a real advantage. Full offline support makes the app more expensive to build and test, so I usually recommend starting with drafts saved locally and only going further if the need turns out to be real.

Who owns the code when the project ends?+

You do. My clients own the code from day one, and it should live in a repository your company controls. The same goes for the domain, hosting and third-party accounts. That way you can switch developers or bring development in-house without starting over, and you're not dependent on one person.