The Shift
From roughly 2015 to 2020, the drone industry competed on hardware. Flight time, payload capacity, wind tolerance, gimbal stabilisation, transmission range. The winners were the manufacturers who could hit the spec sheet and scale production. DJI won the consumer and prosumer segments so completely that for a while "drone" and "DJI" were interchangeable in procurement conversations. The moat was manufacturing: BOM cost, supply chain, firmware tuning, regulatory homologation. Software existed, but it was wrapped around the hardware as a necessary accessory — a mission planner here, a ground station there, enough to make the aircraft useful but never the thing you were really buying.
That era is over. It has been over for long enough that it is now visible in the procurement data. A 2025 Freefly Astro Max, a Quantum Systems Trinity Pro, a Sky-Hopper quadcopter, a Parrot ANAFI UKR — these are all capable SAR airframes. They fly for 35 to 90 minutes depending on platform, they carry payloads sufficient for EO and IR sensors, they handle 10 m/s winds, they operate in GPS-contested environments. None of them are a full operational system on their own. All of them need something to tell them where to fly, what to look for, when to come home, and how to coordinate with the other aircraft in the fleet.
The hard engineering has moved up the stack.
The Commoditisation Is Real
The commoditisation argument is sometimes framed as dismissive of the hardware makers — as if building a 4kg airframe that survives 10 m/s gusts over salt water is trivial. It is not trivial. But "not trivial" is not the same as "differentiated." Multiple manufacturers now produce aircraft that meet the envelope required for professional SAR: a payload class in the 1–3kg range, endurance past 30 minutes, a flight controller that speaks MAVLink or a documented SDK, and a camera system capable of feeding a real-time vision pipeline. Once you have more than one vendor shipping that envelope, the airframe itself stops being the strategic variable. Procurement teams at coastguard, police, and military SAR agencies know this. Their five-year refresh cycles increasingly specify "MAVLink-compatible" and "open payload interface" rather than a particular manufacturer. They are buying a compute substrate and reserving the right to change their mind about who supplies it.
What does not commoditise is the software that runs on top. Fleet orchestration, onboard detection, GPS-denied navigation, exception alerting, mid-flight decision making — each of these is a multi-year engineering problem, and none of them are solved by buying a better airframe.
What The Software Actually Has To Do
Start with mission planning. A useful planner does not just lay a grid over a polygon. It computes sweep spacing from camera FOV and flight altitude, aligns the sweep to the polygon's principal axis, clips sweep lines to arbitrary boundaries, resamples operator-drawn paths into uniform segments so efficiency is independent of vertex count, and respects the wind curve of the specific airframe at the specific altitude. That is the floor. Above it sits sector partitioning for multi-drone patrols, AOI-aware endurance modelling, and fleet sufficiency checks that tell the operator before takeoff whether the mission they just configured is physically flyable with the batteries on hand.
Then navigation. Real SAR operations happen in GPS-challenged environments — cliffs, canopies, urban canyons, reflected-signal shorelines, and increasingly deliberate jamming. A flight plan that is a list of absolute GPS waypoints breaks the moment the fix drops. The software answer is a hybrid GPS/VIO architecture with flight plans stored as relative displacement vectors, so the drone continues the mission off visual-inertial odometry when the satellites stop answering. Building this well — calibrating the VIO baseline against GPS when GPS is healthy, handling the transition without a jerk, recognising when VIO itself is drifting — is years of work.
Then detection. A SAR drone without onboard detection is a flying camera whose video feed has to be watched by a human, and human attention degrades past the ten-minute mark. The software answer is inference on the edge — a TFLite SSD MobileNet running at 5 to 10 FPS on a Snapdragon 845 or a Raspberry Pi companion, geolocating every detection, pushing only the alerts to the operator. The model is the easy part. The hard part is the pipeline around it: frame capture, resize, confidence thresholding, geolocation, deduplication, the honest handling of failure modes under canopy and at night.
Then orchestration. A single drone is a mission. A fleet is a system. Battery-aware relay handoff between two, ten, or a hundred drones requires a continuous tick loop that knows where every airframe is, how much endurance it has left, what altitude band it is flying in, which sector it is responsible for, when its replacement should launch to preserve overlap, and how to avoid mid-air conflicts with the other drones currently in transit. Add multi-sector partitioning, takeoff stagger, altitude deconfliction, runtime collision avoidance as a safety backstop, and a Safety Gate that validates every AI-proposed parameter change against inviolable constraints. This is not a feature. It is the product.
Then, finally, the interaction layer. Exception-only alerting instead of telemetry dashboards — because an operator managing a ten-drone patrol cannot read ten battery gauges, ten GPS fix indicators, and ten video feeds simultaneously, and should not have to. The software filters the firehose down to the events that demand a human decision, and stays quiet the rest of the time.
Each of these is a multi-year engineering problem. Together, they are the product.
Why The Incumbents Struggle Here
Hardware companies are not software companies. This is not a slight; it is an observation about where the talent, culture, and capital have been directed for two decades. The companies that dominate the airframe market built manufacturing organisations. The companies that need to dominate the autonomy market need to build software organisations, and retrofitting one into the other is harder than it looks from the outside.
Skydio is the notable exception, and the exception is instructive. Skydio built a serious autonomy stack, and it shows in the product. But Skydio is also a closed vertical — the autonomy ships on Skydio aircraft and nowhere else. For a SAR agency on a five-year procurement cycle, a closed vertical is a bet that the vendor's hardware roadmap will keep matching the agency's operational envelope forever. It often does not. And when the agency wants to add a second airframe from a different vendor — a long-endurance fixed-wing for coastal runs, a heavy-lift quad for payload-dense missions — the autonomy does not come with them. The agency runs two ground stations, two training programmes, two sets of operational procedures. The open layer that works across airframes is still a greenfield.
How We See It
Overwatch is a software-first company. MAVLink is the hardware interface for the full ground-station product, and AirSDK is the bridge to the Parrot partnership route for single-drone SAR. Both are open protocols. The implication is that the software gets better independent of the airframe — and the airframe gets better independent of the software, which is exactly what an agency buying a fleet over five years needs. A 2025 Astro Max and a 2027 Sky-Hopper should run the same ground station, the same Fleet Advisor, the same Safety Gate, the same detection pipeline. The operator should not care which airframe is under the rotor, only which mission is in the air.
We think open ecosystem beats closed vertical for professional SAR, because professional SAR agencies buy hardware in cycles that do not match any single manufacturer's release cadence. The software layer has to outlast the airframe. That is a different business from selling aircraft, and we have designed the company around it from the start.
The Airframe Is The Substrate
The 2015-2020 era was hardware. The 2023-onwards era is software. The airframe is the compute substrate — necessary, increasingly commoditised, and not the thing that determines whether a fleet finds the person in the water before the sun goes down. The software is what saves lives. It is also, not coincidentally, where the engineering leverage is and where the defensibility will accrue over the next decade.
That is the layer we build.
If you are weighing an airframe choice for a SAR programme, we wrote a companion piece on how to evaluate platforms when the software is the point. If you already know the shape of your fleet and want to see how Overwatch is priced against it, the pricing page is the next click. Either way, the airframe is a decision you will revisit in five years. The software layer should not be.