01Why we started
Building a custom drone is still an artisanal act. A first-time builder spends an average of 22 hours opening browser tabs, cross-referencing datasheets, and second-guessing compatibility, before writing a single line of configuration. The person with the real problem, the farmer, the solar-O&M lead, the search-and-rescue volunteer, rarely completes the trip.
That distance is what we are here to shorten.
02What we are
We are an applied-research team building the conversation layer for physical systems. Our first domain is drones because drones are fast-moving, catalog-friendly, and visually legible, but the pattern extends to any complex assembly.
03What we believe about product
A tool either produces a flyable drone, or it does not. Conversation is the interface; the machine is the output. Physics is deterministic; the model proposes and the solver verifies. We do not ship a design the simulator cannot fly.
04Who we are for
The 14-year-old on a drone-soccer team. The 52-year-old farmer whose cows keep leaving. The facilities engineer who is tired of paying an outside firm to inspect their own roofs. The person who has a problem they do not know how to phrase yet.
05What we won't build
DRONA will not help design weapons systems, loitering munitions, lethal autonomous systems, or payload dispersal for bio or chemical hazards. A design tool is a force multiplier; we are responsible for what we multiply. This line is bright and permanent.
06Where this goes
Version one is a drone designer. Version two is a problem designer. You describe what needs to happen; DRONA determines whether the answer is a drone, a fleet, a tethered sensor, a ground rover, or no machine at all.