The Land-and-Expand Model for Venue Infrastructure

The best infrastructure businesses share a pattern: low-friction entry, natural expansion, and compounding value over time. AWS started with S3 and EC2. Snowflake started with a single data warehouse. Stripe started with seven lines of code.

OZ starts with a PanoNode.

Land: OZ PanoNode#

PanoNode is the lightest deployment in the OZ platform: an edge data sensor for continuous panoramic tracking data capture. It installs at a venue with minimal capital deployment and immediately produces structured spatial data through the Spatial API.

For the venue, the value is immediate: tracking data, spatial context, and event detection from day one. For the platform, the value is strategic: a physical presence at the venue, an integration point for downstream consumers, and a relationship that's now measured in operational output rather than slide decks.

PanoNode proves value before anyone commits to the full production stack.

Expand: OZ VI Venue#

When a venue is ready for full production capability, the upgrade is additive, not a rip-and-replace. OZ VI Venue adds six 4K PTZ cameras with optical zoom, robotic capture heads, expanded on-venue GPU compute, and managed multi-camera orchestration.

The Spatial API contracts stay the same. The data shapes stay the same. The integration code stays the same. Downstream consumers that built on PanoNode data don't need to change anything. They get richer data from the same endpoints.

The upgrade path is designed so that the decision to expand is low-friction: the venue already knows OZ, the operators already know the platform, and the data consumers are already integrated.

Compound: Spatial API and data products#

This is where the economics become infrastructure-grade.

Every downstream consumer that builds on OZ spatial data (analytics companies, coaching tools, fan engagement products, compliance dashboards, betting data feeds) increases the value of each node without increasing the cost of operating it.

More API consumers means more revenue per node. More revenue per node means better unit economics. Better unit economics means faster deployment. Faster deployment means more nodes. More nodes means more data. More data means more API consumers.

This is the deployment flywheel, and it compounds.

Infrastructure margins, not services margins#

The margin profile of this model is comparable to infrastructure companies (Datadog, Cloudflare, Snowflake), not to services companies or production houses.

Why: zero-ops deployment means zero marginal operations cost per node. The same platform, the same monitoring, the same operational playbooks serve every venue. Adding a node doesn't add headcount. The NOC monitors 10 venues or 100 venues with the same team.

As the fleet grows, margins expand. They don't compress. This is the fundamental difference between infrastructure economics and services economics.

Negative churn#

In a services business, revenue per customer tends to plateau or decline over time. In OZ's model, revenue per node increases:

• New Spatial API consumers attach after deployment
• Data products expand as the Venue Graph accumulates history
• Upgrade path from PanoNode to VI Venue increases ASP
• New playbooks (additional sports, additional services) increase utilization per node

A node deployed today generates more revenue next year than this year. That's negative churn, and it's the revenue quality signal that infrastructure investors look for.

The cluster rollout#

The land-and-expand model works best at the cluster level: all venues within a league or region, not scattered individual deployments. Dense deployment within a competitive structure creates better data consistency, stronger playbook transfer, and clearer unit economics proof.

Each cluster validates the economics for the next. Pilot one venue. Expand to the league. Repeat in the next league. Depth wins over dispersion.