QA for the things that move.
QualityMax tests the firmware inside drones, robots and IoT devices — the same way it tests web apps. AI writes the scenarios, the real firmware runs in a simulator, we verify the behaviour and report it in plain language. No hardware required.
In plain words
no jargonThe short version, without the engineering terms:
Drones, robots and IoT gadgets are run by software (firmware) that decides how they behave.
Before that software controls real hardware, you want to be sure it does the right thing — especially when something goes wrong.
So we run the real firmware in a simulator — the actual device behaviour, without the physical risk.
AI writes the test scenarios, including the failure cases: lost signal, low battery, flying out of bounds.
We check every behaviour against live telemetry and report it in plain language — bugs get caught in software, not in the field.
All of it runs in the cloud: reproducible, no test rigs, no crashed hardware, no cost.
In one line: make sure the things that move behave correctly — before they ever leave the ground.
Watch it fly
open full ↗Real recorded PX4 telemetry. Press play — the drone moves on the map exactly as the firmware flew it; scrub to inspect any moment. Two scenarios: nominal mission and a geofence failsafe.
Telemetry over time
open full ↗Altitude and distance-from-home over time, with the asserted phase transitions marked. Hover for the exact values at any instant.
Same flight, in 3D
open full ↗Altitude as the vertical axis — drag to orbit, scroll to zoom. Hand-rolled canvas projection, no 3D engine.
The cloud proof
We took it all the way: a real ArduPilot autopilot running in an E2B cloud sandbox — no GPU, no rig — flew a complete nominal mission, driven over MAVLink and asserted on live telemetry.
[PASS] Vehicle accepted ARM
[PASS] Reached takeoff altitude (~10 m) — 9.1 m
[PASS] Flew to waypoint 40 m north — within 6.8 m
[PASS] Vehicle entered RTL mode — 0.9 s
[PASS] Returned home & landed — 0.0 m, 42.1 s
OVERALL: PASS (5/5)
How this is QualityMax
The same test loop the platform runs for web & mobile apps — just a different transport. Not a separate product.
Does this change what QualityMax is? No — it proves it.
QualityMax was never "a web testing tool." It's an agentic test harness with deterministic guardrails: every capability runs the same altitudes —
The moat is the deterministic harness + verified corpus, not the kind of thing under test. Drone firmware is just a new transport behind the same engine — a new runner next to Playwright / pytest / k6 / Go / Rust, a new target next to a URL.
So it doesn't rewrite the concept — it widens the surface: from "QA for web apps" to QA for anything that runs software, on screen or in the air — while the moat stays exactly the same (and gets stronger as the verified corpus grows).
The same engine — fully inside your perimeter
For regulated, defence and aerospace work, the entire test loop runs on your infrastructure, against your model, under your rules. No prompts, test data or telemetry leave the boundary.
Your cloud, your model. The engine runs against a customer-controlled LLM — on-prem or air-gapped.
Fails closed. If any external cloud LLM key is present, the run refuses to start.
Nothing leaves the boundary. Prompts, test data and telemetry stay inside the perimeter.
Local audit ledger. Every run is written to a tamper-evident log you control.
✓ Fails closed — no external cloud LLM key present
✓ Customer-controlled model — your on-prem endpoint, nothing else contacted
✓ Ran a real task (generated a Playwright test) entirely on your model
✓ Sealed into a local hash-chained, tamper-evident audit ledger
─ sovereign loop complete ─
cloud keys reachable: none · hosts outside perimeter: 0 · data left the boundary: 0 bytes
↑ the real run: fail-closed → sovereign run → sealed ledger. The same harness that flew the drone above — just deployed where the data has to stay. Code in sovereign-demo/.
Now on the drone firmware itself
The same sovereign loop, taken to what a UAV maker actually buys: the customer's model designs an electronic-warfare test (GPS-jamming + comms-loss), the firmware flies it, and we assert on telemetry that it does the right failsafe — dead-reckons through GPS jamming and keeps flying to the target when the link drops. Nothing leaves the perimeter; the run is sealed into the same tamper-evident ledger.
↑ 5/5: control reaches target → GPS jammed (dead-reckons, no flyaway) → link lost (continues, no RTL) → reaches target despite both → and a naive firmware (RTL-on-link-loss) misses by ~1.5 km — which is what attributes the success to the resilient failsafe. Code in sovereign-demo/sovereign_drone_demo.py; the real-SITL runner in e2b-mavlink/scenario_ew.py.
Explore the QualityMax Sovereign architecture and design-partner program →
How it works
Discover the device
Read what it can do — commands, parameters, safety limits.
AI writes the tests
Including the scenarios nobody writes by hand: lost link, low battery, flying out of bounds.
Run, verify, replay
Firmware runs in simulation; every behaviour is checked and played back as a flight you can watch.
What's next
Simulation is the wedge; here's where it goes from there.
From sim to the real device
The same scenario runs on physical hardware over USB via the qmax local agent — simulation for everyone, hardware-in-the-loop as the enterprise tier.
A capability, not a silo
"Embedded / Device" becomes another tile in the Capabilities Marketplace, launched from the same Vibe composer — same shell, different intent.
More transports
MQTT & BLE for IoT feeders and home robots, MSP for Betaflight drones — every new failsafe scenario grows the verified corpus.
Bring us the system you cannot test safely by hand.
Tell us what moves, what can fail, and where the test loop must run. We will reply with a concrete simulator, telemetry, and deployment path for a focused pilot.