01Why we started
Building a custom drone is, in 2026, still an artisanal act. A first-time builder spends an average of 22 hours opening browser tabs, cross-referencing datasheets, second-guessing compatibility, and watching the same tutorials they already watched yesterday. Around 40% of those builders still, after all of that, order at least one incompatible part. They are not stupid. The problem is that drone design is a tangle of interdependent choices — frame wheelbase against propeller diameter against motor KV against battery voltage against ESC current against flight-controller UART budget — and no single tool holds the whole tangle. Reddit holds a piece. YouTube holds another. GetFPV holds a third. The knowledge is there. It is just not assembled for you, in the moment you need it.
Meanwhile the world beyond the hobby builder has the same shape. A farmer in the mountains wants to find his cows. A solar operator wants to inspect a 2 MW rooftop. An archaeologist wants to survey a reef. None of them wake up wanting a drone. They wake up wanting an answer. The drone is the shape that answer takes, and the distance from their problem to the drone is, in every case, far too long.
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 the fastest-moving, most catalog-friendly, and most visually rewarding corner of consumer robotics. They are also small enough that the physics still fits inside a modestly-sized engine, large enough that the economics matter, and broad enough that a single tool can span a tiny-whoop hobbyist and a 60 kg agricultural sprayer and a reef-survey ROV.
If we get drones right, we believe the same architectural pattern extends to unmanned ground vehicles, autonomous surface vessels, fixed sensor networks, and eventually to a lot of physical infrastructure that gets designed once and never looked at again. But we do not want to promise that before we have earned the first domain. So: drones, first, for a while.
03What we believe about product
No hallucinated part numbers, no invented KV ratings, no stack-mount patterns that do not physically exist. If the chat recommends it, the part is in our catalog with verified evidence or it is flagged as estimated. This discipline is the reason we put the physics outside the language model and expose it through typed tool calls. The AI is the interface; the catalog and the compatibility engine are the authorities.
A user never has to know the difference between a deadcat and a stretched-X. They describe what they want to do. The chat picks the form factor, explains the choice in one sentence, and offers one alternative. This is the single most important UX rule in the product.
It is the moment the abstraction becomes real. It is the reason a non-engineer trusts what they are buying. It is also the reason the video travels on the internet. We will keep investing in the visual fidelity of the 3D viewer until a stranger watching a 60-second clip believes they understand what they are looking at.
Zero is pure manual. One is stabilized. Two is GPS-assisted return-to-home. Three is waypoint mission. Four is on-board decisioning with obstacle avoidance and BVLOS-compliant hardware. Each level changes the BOM, the firmware, and the regulatory envelope. We show the user what they are choosing at every level — what it costs, what it requires, what paperwork it triggers — before they commit.
Hold up the camera, drag the image in, and we identify the part and slot it into the build. If the new part breaks the old build, we say exactly what breaks and propose what to adjust. If we cannot identify it, we say so and ask. Silence in the face of uncertainty is a failure mode we refuse.
Every design exports to .vdx — a human-readable, archivable, forkable TOML build spec. Your design is yours. If we go out of business, a decade from now, you will still be able to open the file and know what you built.
The roadmap is not the product. The product is this week's working thing, used by a real person doing a real job. We would rather ship fixed-wing correctly than promise seven form factors and ship none of them well.
Every part in the catalog carries an evidence level: grounded (verified against a live vendor listing), estimated (derived from family-typical specs), conceptual (rough outline only). The lowest tier wins at the build level and is surfaced to the user. We will never pretend to certainty we do not have.
04How we work
Small. Engineering-heavy. Close to users. We fly the drones we design, we ride along on solar-inspection runs, we talk to farmers and archaeologists and marine biologists. A feature that looks right in Figma but does not survive contact with a real operator is not shipped. We rotate authorship on research publications so the work travels with the product, not with individual CVs. We publish methods because an engineering tool without transparent methods does not deserve the word "engineering."
Our first-year operating principle is that the fastest path to a great product is to be disgustingly attentive to five or six users. If you are one of those users, you will notice. If you are going to be one of them and are not yet, we would love to hear from you.