Spray Drone Business Software: Joining Part 137 Records, Pesticide Records and Per Acre Billing in One System

Two record sets, one crew, and nobody joining them

A two aircraft crew works twenty three fields in a day across two counties. Each field needs a flight record for the operating certificate side: aircraft, remote pilot, times, what was dispensed. Each field also needs a pesticide record for the state side: product and registration number, rate, acres, target pest, applicator certification, weather, buffers, restricted entry interval. Then each field needs an invoice line at a per acre rate with a minimum, plus mix cost if you supplied the chemical, plus mobilisation if you moved between counties.

Those are three views of the same event. In almost every operation we have seen, they are three separate reconstructions: a flight log on the controller, a photo of a handwritten mix sheet, and a text to the office with acres. Someone rebuilds all three on Sunday from memory and a camera roll. The acreage on the invoice comes from the grower field boundary, the acreage in the pesticide record comes from what the pilot thought was treated, and the two disagree by four percent that nobody investigates.

The stakes are asymmetric. An invoice error costs you a phone call. A missing or contradictory record when the FAA or a state lead agency asks costs you the authority to operate, and for an operation flying under an exemption there is no version of the business that continues without it.

Why nothing off the shelf fits this business

This category genuinely has no established incumbent, and there is a structural reason. The software that ships with the aircraft stops at the airframe. It plans a mission, flies it, logs telemetry and produces an as flown map. It has no concept of a grower, a work order, a product registration number, a certified applicator, an invoice, or a second aircraft brand on the same job. It is aircraft software written by aircraft companies.

Agronomy and application software goes the other way. It models fields, products, recommendations and records competently, but it assumes a ground rig: one machine, one operator, a rate controller, a boom. It has nowhere to put a remote pilot certificate number, a visual observer, an aircraft serial, a battery set, a swarm of three aircraft on one field, or the exemption conditions your operation flies under. And accounting software knows nothing about acres.

So the operator ends up as the integration layer, which works fine at one aircraft and falls apart somewhere around the third. That is the point where the business is large enough to be worth defending and small enough that a week of missing records is genuinely existential.

There is a second reason packaged software has not arrived. The operating rules for this work are still moving. Aircraft weight thresholds, how many aircraft one remote pilot may supervise, observer requirements and night operations all sit in a mix of certificates, exemptions and conditions that differ between operators. A product vendor cannot encode a moving rule set that varies per grant, so they encode none of it and leave the operator to remember. A system built for your operation can hold your specific conditions and enforce them, which is a genuine advantage of building rather than a consolation for the absence of a product.

What a custom spray drone build has to include

• One job object per field pass that carries both record sets and the billing line. 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, never retyped.
• Offline first capture. You will work fields with no signal and you will not stop flying to wait for a bar. Boundaries, product lists and the whole capture flow cached on the device, with sync that resolves conflicts rather than duplicating jobs.
• Flight log ingestion from more than one aircraft platform. Most growing operations end up flying mixed fleets, and the log formats differ. Treat this as a parser per platform, mapped into your own flight record, rather than assuming a common standard exists.
• Exemption and certificate conditions modelled as rules. Aircraft weight limits, number of aircraft per remote pilot, observer requirements, operating hours, and any condition specific to your grant. The system should refuse to schedule a job that violates the conditions you fly under, because the crew in the field will not have read the exemption document that month.
• Applicator certification and remote pilot currency in one register, with expiry alerts and hard blocks. Two separate credentials, two separate expiry clocks, one crew.
• Mix and chemical inventory drawn per job, distinguishing chemical you supplied from chemical the grower supplied, because that difference changes both the invoice and who owns the record.
• Acreage reconciliation between planned boundary, as flown coverage and billed acres, with the variance shown. This single report ends most billing disputes before they start.
• Aircraft and battery maintenance tracking by cycles and hours, since a battery set is a consumable with a service life and an aircraft down mid season is lost revenue you cannot make up.
• Per acre billing with minimums, zone or distance based mobilisation, and per grower rate cards, generating invoices the same evening rather than the following Sunday.
• An append only record trail. Corrections are visible and attributed. Silent edits destroy the evidentiary value of everything you built.

What it costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this is a smaller build than most agricultural systems because the operation is smaller and the data model is tight. A first release covering field capture, the joined flight and pesticide record, and per acre invoicing runs $35,000 to $85,000 and ships in 8 to 12 weeks. A full platform adding multi crew dispatch and scheduling, mix and chemical inventory, aircraft and battery maintenance, multi state record formats and a grower portal runs $95,000 to $220,000 across 4 to 8 months.

What pushes the price up: the number of aircraft platforms whose logs you need to ingest, since each is its own parser and each vendor changes formats; the number of states you fly in, because each has its own record definition and retention rule; and crew scale, because dispatch across several two person crews in different counties is a scheduling problem rather than a form. What holds it down: building the single job object and the offline capture first and leaving dispatch until you actually have three crews. Most operations overbuild scheduling before they have anything to schedule.

When to stay on spreadsheets

Stay on a spreadsheet if you fly one aircraft solo and treat fewer than a few thousand acres a season. Your record keeping problem is discipline, not software, and a well designed sheet with a phone camera folder genuinely works at that size. The same applies if drone application is a sideline to a ground rig business, because your records should live wherever your ground application records already live rather than in a second system.

Build when two or more of these are true. You run three or more aircraft or more than one crew. You fly in more than one state. You have grown past the point where the office can reconstruct a week from photographs. You have been asked for records by the FAA, a state agency or an insurer and it took more than a day to assemble them. Or you are quoting large acreage contracts where a four percent acreage variance is real money on a single job. That last point converts this from a compliance purchase into a margin purchase, which is usually what gets it funded.

How to choose a developer for a spray drone build

Ask whether they will model the exemption conditions as enforceable rules or as a document you upload. The second answer is a filing cabinet with a login. The first is the thing that stops a crew from doing something on a hot afternoon that costs you the authority to fly.

Ask how they will ingest flight logs from two different aircraft manufacturers and what happens when a manufacturer changes the format mid season. The answer should be a mapping layer you control, not a dependency on a vendor integration you cannot fix.

Ask about offline conflict resolution specifically. Two crews, two devices, no signal, overlapping edits to the same grower job. If they have not thought about it, they have not built for a field.

Ask who owns the code, the repository and the cloud accounts, in writing, before kickoff. At Digital Heroes the client owns the code from the first commit. In a category with no packaged alternative to fall back on, being locked out of your own system is not an inconvenience, it is the end of your record keeping.