DRONE Software Development

CodigoDelSur builds the software that flies the aircraft: native flight applications on the DJI SDK, automated missions, airspace and hardware validation, image capture at a held altitude, and the structured flight logs your customers will need months later for compliance and insurance. We have been building software from Montevideo, Uruguay since 2007, for companies in the United States and the rest of the world.

Drone work is not one job. Flight control, mission planning, image processing and a fleet dashboard are four different products, and a partner who has shipped one of them is not automatically useful on another. This page names four drone products we have worked on, says which of those four jobs we did on each one, and says how long we stayed. It is not a full inventory of our drone work: it is the part we can show in public.

LET’S DISCUSS YOUR BUSINESS NEEDS TODAY

Four drone products we have worked on

Drone software is four different jobs sold under one word: flight control, mission planning, image and map processing, and the dashboard someone looks at afterwards. Here is which of them we did on each product, and what belonged to the client.

Client	The product	What our engineers built	Stack
DroneDeploy	Drone mapping and reality capture for construction, agriculture, energy and surveying	The native iOS and Android flight applications: flight path generation, airspace and hardware validation, pre-flight and in-flight checks, autonomous mission execution, map data exploration and structured flight log exports	Swift, Objective-C, DJI SDK
AgroScout	Precision agriculture platform that detects pests, disease and crop stress from drone, satellite and phone imagery	The mobile application, including a custom flight control loop that bypasses mission planning and takes direct low latency control of the aircraft to hold altitude over sloped terrain. The detection models are the client's own work, not ours.	Objective-C, Swift, DJI Mobile SDK, Mapbox, Android
Skippy Scout	Crop scouting that automates flights to photograph fixed scouting points across fields	The iOS application, including the automated flight and image capture behaviour	Objective-C, DJI SDK
Ware	Warehouse inventory counted by indoor drones, with the results in an operations dashboard	The platform frontend. No flight software on this one: the drones and the indoor navigation were the client's	React

What that table is actually telling you

Three of the four run on the DJI Mobile SDK, and on those three our engineers wrote the code that commands the aircraft. The fourth, Ware, is the honest counterexample: indoor drones, no flight software from us, a React dashboard. We keep it on the page because a partner who presents every drone project as flight work is a partner you will find out about in month two.

The DroneDeploy applications run on more than 3 million jobsites across over 180 countries and have captured roughly 20 trillion square feet of visual data. Procore announced an agreement to acquire DroneDeploy in July 2026, and Ware was acquired by Gather AI, so two of the four ended in an acquisition rather than a shutdown.

Five things drone software has to handle that most software does not

Not a list of trends. Each one is a constraint we hit on a product named above, and it is the reason that code looks the way it does.

The SDK is not an API, it is an aircraft. A drone SDK does not return a value, it moves a machine that can fall. On AgroScout the standard waypoint mission mode was not enough, because it cannot adapt to elevation in real time, so we bypassed mission planning and took direct low latency control of the aircraft, reading telemetry every 10 milliseconds and recalculating the flight as it went. That is also why this work is native: you cannot get to that level of control through a cross-platform layer.

The interface is used outdoors, in gloves, with no signal. DroneDeploy's users are site foremen and drone operators standing on a jobsite with a tablet, often wearing gloves, often with unreliable connectivity. That is not a visual design problem, it is an architecture problem: what the app does while it cannot reach a server decides whether the flight happens at all.

The flight has to be validated before anything takes off. Flight path generation, airspace validation, hardware validation, and the pre-flight and in-flight checks that stop a mission that should not run. This is the least visible part of a flight app and the part that decides whether an operator trusts it, and it is the first thing to look for when you take over someone else's drone codebase.

The log is the product, months later. DroneDeploy's flight logs are exported as structured data because a customer will need them for compliance, insurance and fleet maintenance long after the flight. Data that was good enough to draw a map is not automatically good enough to defend a claim, and deciding that at the end of the project is expensive.

Not every drone flies outside. Ware counts warehouse inventory with indoor drones, where there is no GPS and the product a human actually uses is an operations dashboard rather than a flight app. We built that frontend and none of the flight software, and it is worth saying because "drone experience" covers two jobs that share almost no code.

How long these engagements actually ran

Drone products live or die on hardware and firmware cycles that are not yours, so the useful question is not whether a partner has flown a drone once. It is whether their code survived three years of somebody else's SDK releases. These are the engagements on this page.

Client	When	How long
AgroScout	January 2021 to October 2024	Three years and nine months
Ware	April 2020 to February 2023	Two years and ten months
DroneDeploy	2016 to 2018	Three years
Skippy Scout	September 2019 to January 2021	One year and four months

The DroneDeploy row is the one worth reading twice. Flight software we wrote in 2016 is still shipping in the App Store and Google Play, on hardware and SDK versions that did not exist when we wrote it. That is not a claim about our talent, it is a claim about how the code was structured, and it is checkable in about ninety seconds.

What we build in drone products

Four categories and not fourteen, each one named with the product it shipped in. If something you need is not on this list, it is not because we forgot it.

What we build	Where it shipped
Native flight applications on the DJI Mobile SDK, including direct low latency aircraft control when mission planning is not enough	DroneDeploy, AgroScout, Skippy Scout
Automated mission planning and image capture at a held altitude and a fixed interval	DroneDeploy, AgroScout, Skippy Scout
Airspace and hardware validation, pre-flight and in-flight checks, and structured flight log export for compliance and insurance	DroneDeploy
Operations dashboards and web platforms that sit on top of what the drones collected	Ware, DroneDeploy

Two things that are deliberately not on that list: we do not build the aircraft or its firmware, and we do not train the detection models that read the imagery. On AgroScout those models are the client's. Where we have trained computer vision ourselves it was on a different product and in a different industry, and we say so there rather than here.

What working with us on a drone product looks like

How fast a team starts. Five business days from a signed agreement to the engineer's first day is the standard, and as soon as the next business day if the profile is already on our bench. The minimum term is two weeks, one sprint, and the minimum project size is $10,000, roughly one engineer for one month.

Hours, and why they matter more here. Our engineers work 10:00 to 19:00 Uruguay time, which covers the entire US East Coast working day and five to six hours of live overlap with the West Coast. Drone work raises the stakes on that more than any other kind we do: the bug reproduces outdoors, in daylight, with somebody standing in a field holding a controller. A partner who is asleep at that hour costs you a full test window per iteration, not an hour.

Taking over an existing drone codebase. This is most of what gets asked for in this category, and it is a different skill from starting one. We read the flight code first and the UI last, because the validation and failure paths are where the previous team's assumptions are buried, and we tell you what we found before we agree to a roadmap.

What happens at the end. You own the code, the repositories and the store accounts throughout, not at the end. The DroneDeploy applications are the case to ask us about: we handed them over and they are still in both stores years later, which is the only real test of whether a handover was done properly.

Three ways to engage. Drone work is delivered through the same three models as everything else: staff augmentation, a dedicated team, or full-cycle product development.

If your drones fly over crops, the agriculture page covers the other half of that problem: scouting workflows, pest management across roles, and what happens to the data after the flight. And if you are still building a shortlist, we published a comparison of five drone development partners, ourselves included, with the criteria stated.

Staff augmentation, dedicated team or full-cycle product development

Three different products get sold under the same word, "outsourcing". They are not interchangeable and picking the wrong one is the most expensive mistake in this category. All four drone products above were delivered through one of the three.

	Staff augmentation	Dedicated team	Full-cycle product development
Who owns the roadmap	You	You	Shared, we run discovery
Who manages day to day	Your engineering manager	You, with a CodigoDelSur project manager coordinating on our side at no extra cost	Our project manager
What you get	Individual engineers inside your team	A team shaped around your product, staffed and coordinated by us	A product, from discovery to store release
You need to have	Technical leadership with spare capacity	A product owner and a clear roadmap	A budget and a problem worth solving
Who owns the code, the repositories and the store accounts	You, throughout	You, throughout	You, throughout
Typical size	1 to 4 people	4 to 12 people	Scoped per project
Minimum commitment	Two weeks, one sprint	Two weeks, one sprint	Quoted per project
Best when	The work is defined and you are short on hands	You own a product area and want it staffed and coordinated as one team	You need the thing to exist and you do not have an engineering org

When this page is not your answer

If the hard part of your product is the aircraft rather than the software, we are the wrong supplier and it is cheaper to find that out here. We do not design airframes, we do not write firmware, and we do not build the perception stack that decides what an image contains. What we build is the software a human uses to command the aircraft and read what came back. If nobody on your side owns the hardware and the models, hire that before you hire us.

Where "taking over an existing project" and "short-term work" fit

Neither of those is a fourth model. They are situations, handled inside the models above. If you already have a flight app built by someone else and want to switch providers, we review the existing codebase and work on top of it, either with engineers embedded in your team or with a dedicated team taking the product over. If the work is short, the two week minimum means a single sprint can be the whole engagement, and an SDK upgrade assessment is a reasonable thing to buy that way.

Frequently asked questions

Have your engineers actually used the DJI SDK, or just built drone-adjacent apps?

Three named products on the DJI Mobile SDK: DroneDeploy, AgroScout and Skippy Scout. The level of the work is the part that is hard to fake in an interview: on AgroScout the standard waypoint mission mode could not adapt to elevation in real time, so we bypassed mission planning and took direct low latency control of the aircraft, reading telemetry every 10 milliseconds and triggering the camera at a fixed interval while hugging the terrain. Ask any partner for the name of one drone client and the app in a store. If the answer is a description rather than a name, it is not evidence of anything.

Which part of a drone product do you build, and which part do you not?

We build the flight application, the mission and capture behaviour, the validation and check logic, the flight log export and the dashboards on top. We do not build airframes or firmware, and we do not train the models that interpret the imagery. On AgroScout the pest and disease detection is the client's own work and we built the application around it. On Ware there was no flight software from us at all: indoor drones, and we built the operations frontend. We would rather draw that line ourselves than have you find it later.

Can you take over a drone codebase that another team wrote?

Yes, and it is most of what gets asked for in this category. It is a different skill from starting from scratch: we read the flight code and the failure paths first and the interface last, because that is where the previous team's assumptions about airspace, hardware and connectivity are buried. You get a written assessment of what we found before anyone commits to a roadmap, and one sprint is enough to buy that on its own.

What time zone do your engineers work in, and how much overlap will I get?

Our engineers work 10:00 to 19:00 Uruguay time, which is UTC minus 3. That covers the entire US East Coast working day, five to six hours of live overlap with the West Coast, and three to four hours with Europe, in their afternoon. The schedule is set that way deliberately: shifting the day an hour later widens the Pacific overlap without asking anyone to work nights, and it is the reason this arrangement is still working in month twelve rather than quietly falling apart in month three.

How fast can you actually start?

Five business days from signed agreement to first day is the standard, and if the engineer is already on our bench and your side is ready to receive them, they can start as soon as the next business day. What varies is finding the right person, not starting them: if the profile is on our bench you get CVs one business day after you sign off the role brief, and if the role has to be recruited, first CVs take about five business days. We tell you which of the two you are in on the first call, before you have signed anything, because that is what actually moves your start date.

What happens if the engineer is not working out?

You tell your account manager and we replace the person at our cost. There is no charge for the search and no penalty for asking. The outgoing and incoming engineers overlap for ten business days so that context, access and work in progress transfer inside the engagement instead of landing back on your team, and those ten days are not billed: during the handover you keep paying exactly what you were paying for one engineer. We would rather absorb that than have you carry a bad fit for a quarter, and a company that will not put a replacement policy in writing is telling you something.

Who owns the code and the intellectual property?

You do, exclusively. Everything created for you as part of the work is assigned to you with full title guarantee: source code, application logic, APIs, integrations, data models, configurations, UI and UX designs, documentation and any derivative works. The assignment covers the deliverables as they are created, it is not conditional on final payment, and it is not a licence back to you, it is ownership. We also warrant that what we deliver does not infringe any third party's intellectual property, and where third party material is involved we secure the consents for both sides first. For our own pre existing components that were not written specifically for you, you get a non exclusive, irrevocable, royalty free licence to use, copy and modify them, so nothing we bring with us can be used to lock you in later. Every CodigoDelSur employee signs a non disclosure agreement and an intellectual property assignment as a condition of employment. In a drone engagement that includes the repositories and the store accounts, which stay yours throughout rather than at the end.

Tell us what your drone has to do

Tell us what the aircraft is, what the operator has to be able to do with it, and whether you are starting from nothing or from a codebase somebody else wrote. On the first call we will tell you which of those we have shipped before and which we have not. CodigoDelSur has been building software since 2007, from Montevideo, Uruguay, for companies in the United States and the rest of the world.

FIND OUT MORE ABOUT DRONE SOFTWARE