How 300+ deployed drones continuously improve DroneForge’s autonomy stack

Codex helps us solve the problem in front of us. Alloy turned that into recurring analysis that keeps tabs across the fleet at all times.

David Crabtree, Founding Engineer at DroneForge

DroneForge builds autonomy for drones

DroneForge builds hardware and software that make drone autonomy accessible. Their platform involves the DF1 which handles perception, planning and control, and the Nimbus, a ground module.

DroneForge ships kits across the United States. Autonomous flight demos from its developer community regularly go viral on X, showing drones navigating cluttered offices and coordinating in swarms.

Its software supports a wide range of applications from indoor flight to outdoor drones used in agriculture and construction. DroneForge also supplied drones as an official hardware sponsor for the 2026 South Park Commons Embodied AI Hackathon.

With so many different drones and customers, problems could take many different forms. The company is a lean team of four. Every unexpected flight creates an additional task for the small team to investigate.

Before Alloy, debugging problematic flights was eating up the CEO’s time

Drones do not always behave exactly as expected. That is not unusual, nor is it inherently a problem. The problem was how time-consuming it was to figure out the issue.

Every day, customers contacted DroneForge to understand why a drone had performed poorly. Each question could trigger a new technical investigation: “was the disarm triggered automatically? Did flight performance degrade while the drone was changing yaw? Was it an issue with the camera-frame frequency?”

DroneForge’s CEO was on the front line of answering those questions. Before Alloy, debugging customer flights consumed the majority of his working day.

His workflow looked like this:

1. A customer complained of a poor flight.
2. The CEO searched through tens of thousands of files in an S3 bucket to work out which log file belonged to that customer.
3. He downloaded the correct flight and replayed it locally.
4. He investigated the raw data and found it was an antenna/transmitter fault.
5. He replied to the customer about the root cause and a fix, then updated the code where necessary.

At 300 deployed devices and a rapidly growing flight volume (with 676 flights recorded on their busiest day), that was not a sustainable operating model.

With Alloy, the investigation is done before the customer even complains

Alloy helped DroneForge translate this highly manual and time-consuming process into something automatic and seamless.

Instead of waiting for a customer complaint to start an investigation process, Alloy runs real-time analysis on every new flight record. With its memory system and tribal knowledge, Alloy understands the signature of a “good” or “bad” flight. It understands and remembers David’s heuristic of a tracking anomaly or the signs of poor optical flow quality. Alloy prepares the flight summary and delivers the result to Slack.

So by the time the team looks at a “dodgy” flight, the first layer of investigation is already complete. Alloy then aggregates those results across the fleet, revealing customer-level patterns that would be invisible in any single flight or support ticket. With Alloy, every new flight becomes evidence about whether the product is improving.

These reports are a big part of speeding that process up to something that can happen real-time versus something I have to spend a few hours on before I can offer them a fix.

David Crabtree, DroneForge

When someone asks a follow-up question, Alloy can reply straight to Slack. If users ask Alloy for a 3D trajectory of the flight, Alloy can draw out the coordinates and post the 3D chart directly in the Slack thread. Alloy’s conclusions remain connected to the raw evidence, including the relevant flight, signals and time windows, so an engineer can diagnose and solve the issue faster.

Alloy accelerates the development loop by 3x

Alloy keeps in lockstep with all of DroneForge’s engineering decisions.

DroneForge’s definition of an important flight is constantly evolving. The clearest record of engineering context lives in the code. A new pull request might adjust the state estimator, tune a control parameter or tweak the controls system.

Via Alloy’s MCP integration with coding tools, coding agents automatically tell Alloy what changed and Alloy can figure out which signals it should examine in upcoming flights.

Together, this creates a seamless, almost invisible loop between the live fleet and product development:

1. A drone flies.
2. Alloy analyses the flight and flags to the DF team if anything went wrong.
3. The team identifies what needs attention.
4. Codex implements the code change and merges a PR.
5. Codex gives Alloy the relevant engineering context via MCP.
6. Alloy watches for recurrence across future flights.

In June, the team’s engineering priority was reducing takeoff drift and improving state-estimator behaviour. Alloy was given context about each code change on this and updated its agent notes about what sensors it should pay attention to in upcoming flights. By August, the engineering focus moved onto GPS performance. Alloy adjusted what it should look out for on each flight as engineering decisions were made.

David does not need to manually tell Alloy what it should analyse. Alloy’s analysis keeps pace with the code and the product. That way, it became an essential part of the recurring workflow around the coding agent the team already used.

Alloy helps us understand our flights, and then we can translate that back into how we improve the product.

David Crabtree, Founding Engineer at DroneForge

Supercharging your coding agent with flight data

Alloy’s deep understanding of DroneForge’s flights can also produce insights that become part of the product.

David asked Alloy to investigate how battery percentage translated into remaining flight time. Because Alloy could work across the company’s historical flight data, it created a model estimating how many seconds of flight remained before the battery was depleted.

David then used Codex to find the Alloy report and implement the model in DroneForge’s application.

I asked Alloy to analyze how the battery percentage translates to time and create a model so we can estimate how long in seconds before the battery dies. I asked it to create a report with the model and had Codex find the report and implement it into our app.

David Crabtree, Founding Engineer at DroneForge

The loop continued after the code was written. David updated the recurring report so DroneForge could compare the model’s estimate with what actually happened when drones landed because of low battery.

Alloy discovered a pattern across the fleet, then Codex helped turn that pattern into product code.

Make every customer flight improve your product

With Alloy, DroneForge’s data flywheel spins with minimal manual work.

I don’t want visibility for the sake of visibility. We need to translate that visibility into action.

David Crabtree, DroneForge

DroneForge can now move from a customer flight to an investigation, a code change and a check against future flights. Alloy carries the flight data and engineering context through that process, so the team can see whether a fix worked and catch the issue if it returns.

As the fleet grows, the team can spend less time reconstructing what happened and more time improving how its drones fly.