From University Research to a UAE Startup: One Team’s Journey

At an Abu Dhabi exhibition in January 2024, Khalifa University described a robotics research project that was being turned into a startup called DroneLeaf. The research concerned aerial systems that could adapt when their surroundings or physical configuration changed. Two years later, DroneLeaf reported that visitors at the same exhibition could configure a drone and run a self-learning flight-control sequence themselves. Between those appearances, the project had acquired a different audience. The people looking at the technology could now ask what they would need to use it in their own work. Khalifa University’s UMEX and SimTEX 2024 announcement DroneLeaf’s UMEX and SimTEX 2026 account

That shift from research to an offer for operators is the part of the Abu Dhabi team’s journey the public record can trace. University materials document the origin and exhibitions. The company describes the team, the product and a later industrial collaboration. The sources reviewed do not establish a first paid order, the terms of any university licence or performance in a customer's routine operations. The evidence reaches prospective users and an industrial partner. What happened in a commercial contract remains private.

The research question became a commissioning question

In its 2024 account, Khalifa University connected DroneLeaf with work at its Center for Autonomous Robotic Systems. It described aerial robots designed to respond to changes such as wind, payload and other operating conditions. These examples explain the engineering problem the researchers were working on. They do not establish a set of conditions under which the product is approved or guaranteed to work. The distinction matters when an operator is choosing a system for a specific mission.

DroneLeaf lists Yahya Zweiri as founder, Fahad Almaskari as co-founder, Abdulla Ayyad as chief executive and Mohamad Chehadeh as chief technology officer. Its own chronology dates the founding to 2020. The university’s January 2024 language describes the work being developed for the market at the Khalifa Innovation Center. In February 2025 the university published a feature about the journey from its research lab to a market-facing startup. These dates capture different milestones. They give no basis for assigning a specific incorporation or first-sale date. The company currently lists Abu Dhabi addresses connected with the university and its innovation centre. DroneLeaf’s team and company overview Khalifa University’s February 2025 feature DroneLeaf’s Abu Dhabi contact page

For someone outside the lab, the question is how to make the research usable on equipment they can operate. A research team can configure its own aircraft, collect observations and interpret the result. An integrator evaluating flight-control software has to work out which aircraft and components it can use, what information it must enter and how it knows that setup is complete. It also needs a way to identify when something is wrong. The gap between a working method and instructions another person can follow is a practical part of commercialisation.

Let a prospective user do part of the work

Khalifa University named DroneLeaf in its UMEX 2026 announcement as a startup translating research into software for unmanned systems. DroneLeaf’s own event account described visitors configuring and commissioning a drone, then running a self-learning flight-control sequence. The company also described showing warehousing and inspection applications at the event. The university independently corroborates the exhibition context. The account of what visitors did comes from the company. Neither source provides a controlled comparison, a series of operating logs or a customer acceptance record. Khalifa University’s UMEX 2026 announcement

A hands-on demonstration can reveal a different set of problems from a presentation. The visitor might know the mission they need to run but be unfamiliar with the startup’s configuration process. If they can follow the steps, the team learns something about the interface and instructions. If they need someone to intervene at each stage, the company can identify which parts of onboarding still depend on its engineers. The public record establishes what DroneLeaf says it demonstrated. It does not show how much help each participant received or how they would fare without the exhibition team.

Consider an illustrative UAE inspection buyer evaluating software for an aircraft it already uses. The buyer may need to confirm how the aircraft is prepared, how the mission is monitored and what happens if the operator stops it. It may need a usable record of the inspection rather than a technically impressive flight. An exhibition can help it decide which questions to ask. A field trial would have to define the site conditions, roles, evidence and limits before the parties could judge the result. This example is a way to read the research-to-product transition and does not describe a DroneLeaf customer or flight.

A partner can help turn a technology into a complete offer

DroneLeaf said it jointly developed a drone solution with Sindan UAE and that the solution was presented at Make it in the Emirates 2026. The account identifies a counterpart and a concrete exhibition milestone. It does not say who paid for the work, how the parties divided intellectual property or whether an end customer accepted the system. Treat the collaboration as evidence of work with an industrial partner and the presentation as an event milestone. DroneLeaf’s account of the Sindan collaboration

An Abu Dhabi Investment Office Instagram reel promotes Make it in the Emirates. It provides context for the event where industrial firms and innovators can meet. The reel is separate from DroneLeaf’s announcement. It offers no evidence about the aircraft presented, the collaboration terms or a purchase.

A collaboration of this kind raises a question that a university demonstration can leave open. Which part of the system will the startup provide, and which work belongs to the partner or operator? A flight controller can be one component in a wider solution. The organisation buying it may also need equipment, a way to plan missions, operator training and a support arrangement. Before scaling an offer, a research team needs to work out which of those responsibilities it can repeat and which will vary by site.

The software still has to fit the aircraft

DroneLeaf’s flight controller page describes a companion computer running its control algorithms alongside the aircraft’s autopilot. It also lists compatibility with PX4 and MAVLink and describes automated tuning across payload configurations. That is a more concrete view of what an integrator would evaluate than the general description of an adaptive drone. The vendor’s architecture diagram and feature descriptions do not establish compatibility with a particular aircraft or prove how well it performs under specific conditions. DroneLeaf’s flight controller description

For an integrator, those details point to the work that comes after the research. Someone has to install the components, check communication between them and know which configuration was tested. If the payload changes, the operator needs to know what can be carried forward from the previous setup and what must be tested again. A useful handover would identify the aircraft, the software version and the operating conditions behind the result. Otherwise the next operator may be unable to reproduce it or tell whether their own setup falls within the tested scope.

That makes the setup work a commercial issue as well. If each new aircraft needs support from the researchers who developed the original system, the company needs to budget their time or train someone else to take over. If an integrator can repeat setup from a defined set of materials, the research team can support more installations without attending every one. DroneLeaf’s public description of the architecture and its account of visitor commissioning suggest where to ask those questions. They do not answer how much engineering the company still needs for any given installation.

The company now describes several routes to users

DroneLeaf’s website lists flight-control software and related tools, solutions for tasks such as inspection and warehousing, and services including consulting, commissioning and workshops. It describes different routes for enterprise operators, drone manufacturers and integrators, and research or education teams. These are current descriptions of what the company offers. They show how a research capability can be packaged in several ways without showing what the company actually sells most often. DroneLeaf’s products, solutions and services

The differences matter to an operator. A manufacturer integrating software will care about interfaces, documentation and responsibility for equipment changes. An enterprise buying a defined operational solution will ask who can prepare, support and hand it over. A research group may instead need access to tools and help setting up a lab. The same technical foundation can serve each group, but the amount of work the startup must do can differ. A team that estimates commercial demand from demonstrations alone may miss the staffing and support needed after a buyer chooses a route.

For another UAE research team, the question is which part of the offer a counterpart can evaluate today. A prospective user can try a commissioning step and report where the instructions failed. An industrial partner can define which components it would supply and how it would test the combined system. A buyer can agree what output it needs and what it would pay for. Each step adds a different kind of evidence. A strong public demonstration can make the next conversation more concrete while leaving the commercial decision open.

In DroneLeaf’s case, the public progression is clear enough to distinguish the phases. The university documented the robotics origins. The company later showed how a visitor could work through a setup sequence and reported developing a solution with an industrial partner. Its current site explains several ways it intends to serve users. The missing commercial evidence is equally specific. The public accounts reviewed give no purchase terms, acceptance report or record of sustained use. That is where the question about the next stage belongs.

A founder could carry the same distinction into a pilot review. Record which tasks an operator can perform independently, which need an engineer and which have yet to be tested in the buyer’s environment. Identify who pays for the extra work and who will own it after handover. Then ask whether a second operator would need the same support. Those answers show whether a research result is becoming a repeatable product, a service that needs to be priced separately or a collaboration that still has more development ahead.