Euwyn Poon has a pattern: he builds things that are supposed to work in the real world, at real-world scale, and then he tries to make the next version even more deployable. Long before “space infrastructure” became a common phrase in startup decks, Poon was already operating in the messy middle of hardware and logistics—where the hard part isn’t the prototype, it’s the fleet, the maintenance, the reliability, the customer experience, and the constant pressure to reduce cost per unit while increasing uptime.
That background is now showing up in a new form. Orbital, the company Poon is building, has raised $5 million with an ambitious plan: to launch 10,000 space data centers. The pitch is bold enough to sound like science fiction, but the underlying logic is familiar to anyone who has watched hardware companies grow from “cool idea” into “infrastructure.” Orbital isn’t just trying to build a single satellite or a one-off payload. It’s aiming for a repeatable system—something closer to a network than a project.
To understand why this matters, it helps to start with what Poon already proved. Before Orbital, he built 250,000 scooters at Spin. That number isn’t just a milestone; it’s a statement about operational discipline. Scooter businesses live and die by throughput and reliability. You can’t simply manufacture units and hope for the best—you have to manage deployment, charging or power strategy, repairs, theft risk, software updates, and the constant churn of parts and users. Scaling to hundreds of thousands of units forces a founder to develop instincts about manufacturing quality, supply chain constraints, and the difference between “works in a lab” and “works every day.”
In other words, Poon didn’t learn scale in a spreadsheet. He learned it in the field.
Orbital’s current move—raising $5 million to pursue 10,000 space data centers—suggests the company is trying to bring that same operational mindset to space. Space is often treated as a domain where progress comes from breakthroughs in physics or materials. But the reality is that space infrastructure is also a logistics problem. Launch schedules, integration timelines, regulatory approvals, orbital mechanics, ground segment operations, and long-term reliability all determine whether a system becomes useful or remains a demonstration.
The unique twist here is the scale target. Ten thousand “data centers” implies a distributed architecture: many small nodes rather than a handful of large ones. That approach is increasingly common across space tech because it can reduce the cost and risk of any single failure. If you’re building a network, you don’t want your entire service to depend on one expensive asset. You want redundancy, coverage, and the ability to expand capacity by adding more nodes.
But there’s a catch: distributed networks only work if each node is cheap enough to deploy in large numbers and reliable enough that the network doesn’t collapse under its own complexity. This is where Poon’s scooter experience becomes relevant again. In terrestrial networks, scaling is mostly about engineering plus operations. In space networks, scaling is engineering plus operations plus time delays plus the inability to “send someone out with a wrench.”
So what does Orbital mean by “space data centers”? The phrase itself is doing a lot of work. A data center isn’t just a box with compute—it’s a system that includes power, cooling (or thermal management), networking, storage or processing, security, and a way to connect to users. In space, those requirements translate into constraints: limited power budgets, harsh thermal cycles, radiation effects, and communication bandwidth limitations. If Orbital is serious about 10,000 nodes, it likely has to treat each node as a standardized module with predictable performance characteristics.
That standardization is the key to making the math work. If every unit is custom, you don’t get scale—you get a bespoke program. If every unit is a variant of a common design, you can iterate faster, negotiate better with suppliers, and reduce manufacturing costs through volume. The scooter playbook again: once you’ve built a fleet, you learn how to design for repeatability.
Orbital’s $5 million raise is not, by itself, enough to build and launch 10,000 fully independent satellites with full ground infrastructure and long-term operations. That’s not how most space startups operate. Early funding typically supports a combination of engineering development, prototyping, early manufacturing planning, and the initial steps toward deployment—often including partnerships that can carry some of the cost burden later. In other words, the raise is likely meant to de-risk the path from concept to deployable system, not to pay for the entire end-to-end network immediately.
Still, the ambition signals something important: Orbital is positioning itself as a platform company rather than a one-off mission provider. Platform companies don’t just sell a capability; they build a repeatable pipeline that can produce capacity over time. If Orbital can establish a credible roadmap for manufacturing and deploying thousands of nodes, it could become a foundational layer for other services—similar to how cloud infrastructure providers became the default substrate for modern applications.
Why would anyone want space-based data centers in the first place? The most straightforward answer is latency and connectivity. Space can provide coverage where terrestrial networks are weak or unavailable. It can also support specialized workloads that benefit from global reach or from being “closer” to certain users than a purely ground-based system. Another angle is resilience: distributed space assets can provide continuity during disasters or disruptions that take down local infrastructure.
But the deeper reason is that AI and data-hungry applications are pushing demand for compute and networking in ways that don’t always fit neatly into existing infrastructure models. As models grow and inference becomes more frequent, the bottleneck often shifts from raw compute to data movement, bandwidth, and the ability to serve requests reliably at scale. Space-based systems can be part of a broader architecture that offloads certain tasks, improves coverage, or enables new types of connectivity.
That said, “space data centers” also raises skepticism. Data centers require stable power and predictable performance. Space adds variability: communication windows, orbital dynamics, and the need to coordinate with ground stations. Any credible plan has to address how the network handles intermittent connectivity, how it routes data, and how it ensures that the compute/storage layer remains usable even when links fluctuate.
This is where Orbital’s operational DNA could matter. In scooter networks, the system is constantly adapting to real conditions—weather, rider behavior, device failures, and uneven demand across geographies. A well-run fleet uses telemetry and software to keep the service functioning despite imperfect conditions. Translating that to space means building robust monitoring, fault tolerance, and automated recovery strategies. It also means designing the system so that partial failures don’t turn into total outages.
If Orbital is aiming for 10,000 nodes, it likely needs a control plane—software that can manage the network, schedule communications, and coordinate tasks across nodes. That control plane becomes the brain of the operation. Without it, you end up with a pile of hardware that can’t deliver consistent service.
The $5 million raise, then, can be interpreted as funding for the “boring but decisive” work: engineering the architecture, validating components, building early prototypes, and proving that the system can be manufactured and operated reliably. In space, the difference between a compelling demo and a scalable product is often hidden in details: thermal design margins, power conversion efficiency, link budget assumptions, error correction strategies, and the practicalities of integration and testing.
There’s also the regulatory and compliance dimension. Space networks aren’t just technical—they’re governed. Frequencies, orbital slots, licensing, and coordination with other operators all shape what you can do and when. Even if Orbital’s immediate goal is not full deployment, it still needs to navigate these constraints early to avoid building toward a dead end. A founder who has scaled operations on Earth may be unusually aware that “paper approvals” and “real-world execution” are different games. In space, that gap can be fatal if ignored.
Another question investors and partners will ask is: who is the customer? Space infrastructure can be sold to governments, telecom providers, enterprises, or developers building applications on top of the network. Each customer type has different procurement cycles, security requirements, and performance expectations. A network that aims to scale to 10,000 nodes needs a demand signal strong enough to justify the long-term investment. That demand could come from a specific use case—such as connectivity for remote regions—or from a broader platform strategy where Orbital sells access to capacity rather than selling a one-time mission.
Orbital’s messaging around “data centers” suggests it wants to be more than a connectivity layer. It wants to offer compute and storage capabilities in space, which could enable workflows that are difficult to run efficiently on the ground. For example, certain types of processing might be done closer to where data originates (like sensors in orbit), reducing the amount of raw data that must be transmitted back to Earth. That can lower bandwidth costs and speed up response times. It can also improve privacy or security by processing sensitive data in a controlled environment rather than streaming everything to ground.
But again, the feasibility depends on the specifics: what kind of compute, what kind of storage, what kind of networking, and how the system integrates with user endpoints. The term “data center” can mean many things, from edge compute to full-fledged storage and processing clusters. The more Orbital can clarify its architecture, the more credible the 10,000-node vision becomes.
There’s also a strategic angle that makes this story feel timely. Many space startups have historically focused on building satellites or launching payloads. The industry is shifting toward networks and services—constellations, ground segment automation, and software-defined operations. The winners in this shift will likely be the companies that can combine hardware manufacturing with software orchestration and operational excellence. Poon’s background suggests he understands that the software layer is not optional; it’s what turns hardware into a service.
In scooter networks, software determines routing, pricing,