Scaling Mapping Operations

The MVP launched with 50 mapped locations and the roadmap calls for 500 by year end, which means everything about how we map has to get about 10x cheaper and faster at the same time.

The Mapping Pipeline

For each location:

1. Site survey - Identify mapping area, access, timing
2. Capture - Collect imagery with calibrated equipment
3. Processing - Run SfM/MVS to create 3D map
4. QA - Verify accuracy, completeness, safety
5. Publishing - Make available to VPS queries
6. Maintenance - Monitor and update as needed

Each step has its own scaling bottleneck, and they do not all yield to the same fix.

Capture

Today capture means in-house teams with specialized equipment: $5,000+ per location, 1-2 days on site, and a capacity of about 10 locations a month. That model does not get anywhere near 500. It is also not the model in the original architecture, where the mapping input was crowd-sourced images with metadata. A year in, the input is a crew with a calibrated rig, and crowdsourcing is a supplementary line in the plan below.

The scaled version leans on a partner network and consumer devices: mapping partners in multiple countries, lower-cost capture equipment, and crowdsourced supplementary imagery. The target is $500 per location and 100+ locations a month.

Processing

The current pipeline is manual with expert oversight. Processing takes 2-3 days per location, human review eats 4 hours per location, and 20% of runs need manual intervention.

The scaled pipeline automates with exception handling. Processing drops to 8 hours through faster hardware and optimized code, human review drops to 30 minutes because it only touches exceptions, and better preprocessing brings the intervention rate down to 5%.

QA

We check four things: geometric accuracy (does the map match reality), completeness (are all the important areas covered), safety (are there inappropriate elements), and consistency (does it integrate with adjacent maps). Today every output gets a manual review. At scale, automated checks catch 90% of issues and humans sample-review the remaining risk.

Where do we map first?

We cannot map everywhere at once, so prioritization comes down to developer demand (where do partners want to build), user density (where are the Quest users), strategic locations (landmarks, venues, campuses), and capture efficiency (clustered locations are cheaper than scattered ones). An interactive prioritization dashboard puts those trade-offs in front of the business decision makers.

Operational Metrics

The weekly operational review runs on five numbers: coverage velocity (locations per month), cost efficiency (dollars per location), quality rate (percent passing QA the first time), time to publish (capture to live), and partner performance (quality and speed by partner).

The Chicken-and-Egg Problem

Developers want coverage before they build. We want demand before we expand coverage. The way out is unromantic: seed coverage in strategic areas, lock in committed partnerships where coverage exists, demonstrate value to attract more developers, and let that demand drive the next round of expansion. Breaking the cycle takes upfront investment in coverage, and there is no accounting trick around it.

Lessons from Month 1 of Scaling

The external mapping partnerships on last December's list exist now, and partner training takes longer than expected. Local regulations vary a lot by country. Weather windows are real constraints, and quality consistency across partners is genuinely hard. None of this shows up in the spreadsheet that says 500 by December, which is exactly why the processes have to be solid before the scale arrives.