Introduction
On this page 4
Open Farming is autonomous drone scouting and targeted treatment for farms. A drone flies a fixed route over a field, models locate what is actually wrong, and the findings become a prescription the machine you already own can load.
The claim the product makes is narrow and testable: most of a field does not need most of what gets applied to it. On the demonstration field, a 24.6 hectare block of winter wheat, 98 weed detections cluster into 62 treatment zones, and the prescription switches the boom on over 4.34 hectares. The other 20.26 hectares are clean ground that would otherwise have been sprayed because nobody knew which parts carried weeds.

The map on that page is the argument. It is drawn from the stored flight record rather than illustrated, so the orange is the prescription and the dots are the detections. The interface shows every other page.
The shape of the product
Three things happen, in order, and the platform is organised around them.
| Stage | What it means | Capabilities |
|---|---|---|
| Detect | Sensing flights that find the problem while it is still small | 7 capabilities |
| Act | Treatment that follows the map, so only the affected ground is touched | 6 capabilities |
| Operate | The service, the fleet and the reporting that keep it running | 5 capabilities |
A capability is a job the platform does. A use case is the same platform seen from the seat of one kind of operation: a wheat grower, a vineyard, a dairy, a contractor. Use cases exist because the question a grower asks is never "which capabilities do you have", it is "what does a season on my crop look like".

Every capability is that same loop. What changes between them is the sensor on the aircraft and what the model is looking for.
What the drone does and does not do
This matters more than any feature list, because it is where most drone agriculture marketing stops being true.
In Germany and most of the EU, aerial application of plant protection products is prohibited by default. In German law that is Pflanzenschutzgesetz §18, with narrow exemptions, the most prominent being steep vineyard terrain where ground machinery cannot work safely. There is no general permission to spray arable land from a drone, whatever an aircraft's brochure implies.
So the honest product shape is:
The drone finds it, and the machine that is already allowed to treat it does the treating.
The drone's output for a treatment job is a prescription map, in the format your sprayer or spreader terminal expects. The section control on the boom you already own is what opens and closes the nozzles. Where an exemption applies, the same maps drive drone application directly. See Regulation for what that means in practice, and Prescriptions for how the file is written.
Two capabilities have a different legal footing worth knowing about up front:
- Wildlife detection before mowing is a search flight, not an application, and in Germany the duty to take reasonable precautions before mowing sits with whoever runs the mower. It is the single most defensible first flight most operations will make.
- Drone seeding broadcasts seed, not plant protection products, so §18 does not reach it. Aviation rules still do.
The design principle behind the code
Every number on the marketing site is rendered from data, not typed into copy.
app/Support/content/features.tsanduse-cases.tsare the source of truth for capability and use case content.app/Support/content/demo-field.tsgenerates the demonstration field from a fixed-seed PRNG, with noDateand noMath.random, so it is identical on every machine.buddy catalog:syncpublishes both into the database.- Pages and the public API read that database through one shared layer,
app/Support/catalog.ts.
The consequence is that /features and /api/features cannot disagree, and
the treated-hectare figure in the copy cannot drift away from the map that
draws it. If they ever diverge, that is a bug, not a stale copy.
It is modelled data rather than a customer's field, and the site says so
wherever it appears. /api/field-report carries sample: true in the payload
for the same reason.
What this documentation covers
| Section | Contents |
|---|---|
| Guide | Running, extending and deploying this repository |
| Capabilities | All 18, each with its sensors, cadence, readings, parts list and in-house software |
| Use cases | All 16, grouped by segment, with the season each one is flown to |
| Build | Airframes, sensors, positioning, compute, docks, payloads, the software stack, costs, suppliers and regulation |
The build section exists because the interesting part of this business is not the aircraft. Anyone can buy an aircraft. The interesting part is that the software which turns imagery into a prescription is normally rented by the hectare, and it does not have to be. Every build page names the open-source component that replaces the licence, and is honest about what the replacement costs you in engineering time.