OrbitalXploration

The problem

Space tech startups combine hardware, software, mission engineering, and regulatory work under one small team. Technology direction requires making architecture decisions that hold up across all four domains and don't collapse under the first pivot. The pivots are inevitable — mission scope, hardware provider, regulatory jurisdiction, and funding milestones all move in early-stage space work. The leadership challenge is picking architecture that gives the team optionality without incurring the cost of premature abstraction, and doing it while making the ordinary product-engineering decisions any early-stage company faces.

Key challenges

Space tech engineering has unusual constraints: mission timelines measured in months for planning and years for execution; regulatory approvals that can invalidate design choices late; hardware providers whose delivery cycles don't align with software iteration; and data platforms that need to handle telemetry at rates and shapes normal enterprise systems don't see. Directing architecture across these constraints is a full-time leadership job.

What we built

AR Data served as Technology Director for OrbitalXploration — setting technology architecture across mission planning, ground systems, and data platforms. The role covered technical direction, hiring and team composition, vendor evaluation, and the architectural decisions that had to survive multiple pivots. Architecture focused on decoupling the mission planning layer from hardware-specific interfaces, standardizing telemetry ingestion patterns across expected data shapes, and building the data platform for both real-time mission control and post-mission analysis. Each decision was made with the assumption that hardware providers and mission scope would change; the architecture had to survive both.

Our approach

1. 1

   Decouple mission planning from hardware specifics

   Hardware providers change. Coupling mission planning to hardware-specific interfaces creates rewrite risk on every provider switch. Abstraction was mandatory.

2. 2

   Standardize telemetry ingestion patterns

   Telemetry shapes vary by mission and by provider. Standard ingestion patterns absorb that variance without changing the downstream data platform.

3. 3

   Data platform for both real-time and analytical use

   Real-time mission control and post-mission analysis have different requirements. Building for both from the start avoided the retrofitting cost.

4. 4

   Vendor evaluation with pivot-cost weighting

   Every vendor choice has pivot cost. Weighting that cost into vendor evaluation preserved optionality.

Key architectural decisions

Results

• Technology architecture across all four domains (mission, ground, hardware interface, data)
• Mission planning + ground systems decoupled from hardware specifics
• Data platform sized for real-time mission control and analytical use
• Executive-level technical leadership through multiple architecture cycles
• Vendor evaluation with pivot-cost weighting preserving optionality

Impact

Serving as Technology Director for OrbitalXploration was a full-cycle engagement — from architecture through team building through vendor selection. The patterns applied (decoupling, standard ingestion, dual-mode data platforms) are the same ones we bring to any complex-domain technical leadership engagement.

Tech stack