Spray Drone Application Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does building dispatch and scheduling first happen so often?

Scheduling is the thing an owner thinks about at six in the morning, so the first specification describes a board with crews, jobs and a map. Three months later there is a decent dispatch tool and the records are still being rebuilt on Sunday from a camera roll, because the capture work sat behind the scheduling work and scheduling was more fun to build.

This ordering is particularly costly in aerial application because dispatch has no compliance value. A beautiful schedule proves nothing to a regulator, an insurer or a grower disputing acres. The record does. And the record is the thing that is hardest to reconstruct after the fact, because the pilot who flew field seventeen is on a different farm by Thursday.

Build the single job object first. One record per field pass carrying aircraft, remote pilot, applicator certification, product and registration number, rate, mix, acres planned and acres actually treated, start and end times, weather, buffers and the invoice terms. Captured once in the field and never retyped. Once that exists, the flight record, the state pesticide record and the invoice line are three views of one thing rather than three reconstructions.

Leave dispatch until you genuinely have three crews to dispatch. Most operations overbuild scheduling before they have anything to schedule, and the money would have been better spent on offline capture that works in a field with no signal.

What goes wrong with acreage, field boundaries and flight log history?

Three acreage numbers exist on every job and they quietly diverge. The grower's field boundary says one thing. The as flown coverage from the flight log says another. The number on the invoice says a third, often because a pilot texted an estimate to the office. Nobody investigates a small difference, so the divergence compounds across a season until a grower with their own agronomy platform queries a bill and there is no way to settle it.

Boundaries are the underlying problem. They arrive from growers, from agronomy platforms and from the aircraft manufacturer's planning tool, in different formats and different coordinate assumptions, and a boundary that includes a headland, a waterway or a section already treated by a ground rig will not match what the aircraft covered. Importing boundaries without reconciling them to what you actually bill produces confident wrong numbers.

Historical flight logs are the third piece and they are usually not worth what people expect. Logs sitting on controllers and memory cards from previous seasons rarely carry the grower, the product or the certification data that would make them useful as records, so importing them produces telemetry with no compliance value.

Track all three acreage figures per job and show the variance on the record. Most disputes disappear once the difference is visible, because you either find a genuine coverage problem or you have evidence to hold the invoice. Store boundaries with their source and the date received so a changed boundary is a versioned event rather than an overwrite. And do not migrate historical logs during the build. Import them after the season if there is a reason, and be honest that the reason is usually curiosity rather than compliance.

Why do flight log and accounting integrations break after launch?

Mixed fleets are the norm within two seasons, and each manufacturer emits its own log format. Those formats change at firmware updates, without notice, in the middle of a spray window. If the ingestion depends on a vendor supplied integration rather than a mapping layer you control, a mid season change leaves you waiting on someone else's release while jobs pile up unrecorded.

The subtler failure is partial parsing. A format gains a field and the parser keeps working, mapping most of the record correctly and silently dropping or misreading one value. As flown acreage that is quietly wrong is worse than acreage that is missing, because it flows into billing and into the record without anyone questioning it.

Accounting integration breaks on the invoice side. Per acre billing with minimums, zone or distance based mobilisation and per grower rate cards produces line structures that a general ledger integration written for simple invoices will flatten. Then a grower queries a mobilisation charge and the accounting system has no idea what it was for.

Own the parsers, one per platform, mapped into your own flight record, with a version check that rejects an unexpected file shape loudly. Reconcile parsed acreage against the job's planned acreage and flag differences beyond a tolerance. And push invoices with their line detail intact rather than as a single total, since the whole point of billing from the job record is that every line traces back to something that happened.

What happens when exemption conditions and state record formats are not covered?

Operations in this category fly under a mix of certificates, exemptions and conditions that differ between operators. Aircraft weight thresholds, how many aircraft one remote pilot may supervise, observer requirements and operating hours are specific to your grant, not to the industry. The document sits in a folder and nobody has read it since it arrived.

The failure happens on a hot afternoon in a distant county when a crew makes a reasonable operational decision that quietly violates a condition. Nobody involved is careless. The person who read the exemption is not the person deciding, and the software gave them no reason to pause.

Model the conditions as enforceable rules that block scheduling and block job start, not as an uploaded document. A system that will not let you assign a fourth aircraft to one remote pilot, or start a job outside permitted hours, is doing the only job that matters here. Applicator certification and remote pilot currency belong in the same register, with two separate expiry clocks and hard blocks rather than reminders.

State pesticide record definitions are the second uncovered gap, and they differ by state along with retention rules. An operator crossing a state line picks up a second set of required fields, and a system built around one state will silently produce incomplete records in the other. Confirm the current requirements with the Federal Aviation Administration and each state lead agency rather than with a software specification, and make the record template a per state configuration.

Should you build custom or configure what you already own?

Stay on a spreadsheet if you fly one aircraft solo across a few thousand acres a season. Your record keeping problem is discipline rather than software, and a well designed sheet with a dedicated photo folder genuinely works at that size. We would tell you that before quoting, because a build at that scale costs more than it returns.

Use what you already have if drone application is a sideline to a ground rig business. Your records should live wherever your ground application records already live, in whatever agronomy or application software you run, rather than in a second system that fragments the same grower's history across two places.

Do not attempt to rebuild the aircraft manufacturer's mission planning and flight software. It plans, flies, logs telemetry and produces an as flown map, and that part works.

Build when two or more hold. You run three or more aircraft or more than one crew. You fly in more than one state. The office can no longer reconstruct a week from photographs. You have been asked for records by a regulator or an insurer and it took more than a day to assemble them. Or you are quoting large acreage contracts where a few percent of acreage variance is real money on a single job, which is the point at which this stops being a compliance purchase and becomes a margin purchase.

How do hidden costs get into the quote?

Aircraft platform count is the first. Each manufacturer's log format is its own parser with its own maintenance burden, and a quote covering flight log ingestion without naming the platforms will be reopened the first time you add a different airframe.

State count is the second and it is priced as a checkbox far too often. Each state's record definition, required fields and retention rule is configuration plus verification, and verification means someone reading the current state requirement rather than a developer assuming.

Offline capability is the third and it is the one that surprises people. Working properly without signal means cached boundaries and product lists, a full capture flow on device, and conflict resolution when two crews edit overlapping data and sync hours apart. That is real engineering, and a quote describing a mobile app has usually priced a form that needs a connection.

Then the quieter ones. Battery and aircraft maintenance tracking by cycles and hours, which is small to build and easy to leave out. Rate card configuration per grower, which grows as you win accounts. Devices and mounts for crews, which is hardware nobody puts in a software budget. And the two weeks of parallel running where one crew uses the new capture while the old process continues, which is how you find out whether the flow survives a real day.

What separates a build that works from one that fails here?

Ask whether exemption conditions will be enforceable rules or an uploaded document. The second answer is a filing cabinet with a login. The first is what stops a crew from doing something on a hot afternoon that costs you the authority to fly, and it is the clearest test of whether a developer understood the brief.

Ask about offline conflict resolution specifically. Two crews, two devices, no signal, overlapping edits to the same grower job, syncing three hours apart. If they have not thought about it, they have not built for a field, and you will get duplicate jobs and lost captures in your first busy week.

Insist on an append only record trail. Corrections should be visible and attributed rather than silently overwriting the original, because the evidentiary value of everything you built depends on it. A record that can be quietly edited is a record an insurer or a regulator can discount entirely.

Settle ownership of the code, the repository and the cloud accounts in writing before kickoff. At Digital Heroes the client owns the code from the first commit. This matters more here than in most categories, because there is no packaged product to fall back on, so being locked out of your own system is not an inconvenience. It is the end of your record keeping.