46 Releases, 5 Products, 24 Months: What Shipping Velocity Looks Like at the Edge

Shipping fast is table stakes for software companies. Shipping fast when your product includes sealed hardware enclosures, robotic gimbals, edge GPU compute, and live broadcast SLOs? That's a different kind of velocity.

The stack#

OZ operates five products, each serving a different layer of the visual intelligence stack:

OZ VI Venue (v2.0 → v3.2, 16 releases). The full production node. Six 4K PTZ cameras, robotic capture heads, on-venue GPU compute, managed networking. This is the hardware and runtime that lives at the venue.

OZ Studio (v1.0 → v2.2, 9 releases). The operations platform. Remote production control, live monitoring, multi-venue management, operator workflows. This is where human oversight meets autonomous operation.

OZ Designer (v0.1 → v1.5, 10 releases). Pre-deployment planning. Scene design, capture policy definition, zone configuration, deployment templates. This is where venues are designed before hardware ships.

Spatial API (v0.1-alpha → v0.6-alpha, 6 releases). The data layer. Structured spatial intelligence output: tracking data, event timelines, skeletal pose, zone activations. This is where downstream consumers build on OZ.

OZ PanoNode (v0.1 → v1.0, 4 releases). The entry node. Edge data sensor for continuous tracking data capture. Lightweight deployment that establishes venue presence before full production upgrade.

Why the version numbers matter#

The version progression tells a story that release counts alone don't capture:

OZ VI Venue went from v2.0 to v3.2 in this period, not from v0.1. The product had already reached production maturity before this cadence started. The 16 releases during this window span hardware abstraction, player fusion, video routing, GPU graphics, edge-sovereign runtime, and CLI diagnostics, refinements to a system already operating under broadcast SLOs, not early-stage iteration.

Spatial API moved from v0.1-alpha to v0.6-alpha across 6 releases, rapid iteration with real integration partners, evolving the schema based on actual consumption patterns.

OZ PanoNode went from v0.1 to v1.0 GA in 4 releases, the fastest product to reach general availability, built on top of platform capabilities already proven in VI Venue.

Why this velocity is hard to replicate#

Shipping 46 releases across 5 products in 24 months is not primarily a function of team size or development speed. It's a function of owning the full stack.

When OZ identifies a latency bottleneck in the inference pipeline, the fix can be a model architecture change, a TensorRT optimization, a runtime scheduling adjustment, a hardware thermal management update, or a combination, and it ships as one coordinated release across the relevant products.

When a competitor identifies the same bottleneck, they file a ticket with their hardware vendor, wait for their cloud provider to update their inference service, and coordinate across three separate vendor release cycles.

Vertical integration compresses the iteration loop. Owning the stack from enclosure to API means every improvement ships on the next release cycle, not the next vendor cycle.

Every release is deployed#

This is the part that matters most: every one of these 46 releases is not a version tag in a repository. It's deployed, measured, and operating at live venues under production SLOs.

The difference between "shipped" and "deployed and operating" is the difference between a software company and an infrastructure company. Software ships to repositories. Infrastructure ships to the physical world and operates there indefinitely.

39 times in 24 months, OZ pushed updates to physical hardware at live venues, validated the deployment under real match conditions, and maintained uptime commitments throughout. That's the velocity that compounds into operational maturity no competitor can shortcut.