The Challenge for Space Startups

In ",,Space Startup Observations," I tried to make sense of the new space startups tie-in with Silicon Valley startups. In that analysis, I established that space startups, while they might speak the same language as their Silicon Valley counterparts (especially during investor presentations), are not at all like them. In this second part of the analysis, I’ll observe that Space startups aren’t even on the same playing field as the Silicon Valley startups they try to emulate.

Let’s get into why.

Bundled Services

The software sector has a huge advantage over companies having a go in the space sector: the infrastructure was already in place to support their activities. Google founders didn’t have to worry about power plants, power grids, food supply, a lack of coding standards, etc. when they started--most of it was in place. The founders didn't even have to worry about the availability of the medium they were experts on: communications and the internet.

The founders provided the ideas, the algorithms, and code while being supported by a very comprehensive infrastructure initially emplaced courtesy of the government. The companies running these infrastructures today still receive some sort of government support.

With the exception of GPS-type constellations, space infrastructure isn’t even close to providing that kind of support. Unlike the network and coding roots of the tech sector that inspired the space startups, there is no equivalent in the space industry to common coding standards or fairly well-established space-based power and communications networks. Not even memes.

Instead, space startups are faced with the requirement to supply their own infrastructures--and that’s just so they can eventually get to the space equivalent of algorithms and code to implement their ideas. Power, transportation, communications in space and on the ground--it’s a miracle new space companies like SpaceX, Planet, Rocket Lab, and others even decided to start a space business. These infrastructure requirements are also why starting a space business costs much more than starting a software-based business.

Building Infrastructure

Looking at SpaceX and Rocket Lab as launch service providers who are working on basic transportation infrastructure. Launch vehicles were and are expensive to build and launch.

SpaceX’s most recent approach to launch affordability is to use inexpensive materials for building transportation vehicles, which in turn makes manufacturing them much less expensive. And then make those rockets reusable. Rocket Lab’s approach capitalizes on the trend of increased use of smallsats. These smallsats might cost more per kilogram to launch with Rocket Lab than with SpaceX, but it’s still more affordable with Rocket Lab than with other commercial options. Both approaches seem attractive to certain satellite operators.

Satellites themselves might be extremely expensive. In attempting to build up a very basic communications infrastructure, companies like SpaceX and OneWeb strove to keep satellite manufacturing costs down.

Even though their satellites aren’t as expensive (not even close) as a typical geosynchronous communications satellite, they still have high costs: ~$300k for a Starlink satellite, and ~$1 million for an OneWeb satellite. Launching those satellites requires a variety of infrastructure and all sorts of large equipment, including the booster. On top of that is the costly regulation of radiowaves imposed by governmental gatekeepers like the Federal Communications Commission (FCC) and the International Telecommunication Union (ITU).

Other companies using satellites, such as Capella Space and Skybox, had to consider more than just their satellites’ sensors for their constellations to be useful. I believe these companies--and others--significantly overvalued/oversold collected data and software while underestimating the hardware/infrastructure component (this problem exists with ,,DoD space programs, too). They have to also deal with communications infrastructure in space and on Earth. They have to consider the power supply. On top of that, they must worry about running afoul of government security concerns, coordinating with the National Oceanic and Atmospheric Administration (NOAA) as well as possibly dealing with the FCC/ITU.

In Capella’s case, the company is working with technology that is expensive--synthetic aperture radar (SAR). That SAR payload alone drives many different tradeoffs and costs for the rest of the satellite. The company even has to worry about the quality of the data produced by its SAR payload. But Capella has at least also chosen not to build infrastructure hardware (which would be very expensive), instead contracting with Amazon Web Services’ Ground Station service (probably a wise choice).

Advantage: Space Startups (but something’s missing)

All this adds up to Capella and other space startups facing very different challenges than their software/technology-sector counterparts. Challenges that the tech-sector companies take for granted. However, the space startups are also different from legacy space companies because most exhibit some tech-sector startup traits: they move faster; they don’t hesitate to implement change; they accept risks (as do their backers), at levels that are unacceptable to many legacy space companies and their government customers.

Using these characteristics, the startups confront the same challenges legacy companies have faced for decades. They are attempting to build infrastructure along with their missions, typically a government-managed task requiring a lot of money. They are attempting to build it for and in a very challenging environment.

Some startups, like OneWeb, will initially fail and gain government assistance--which will likely ensure some sort of low Earth orbit (LEO) broadband constellation will exist. Others, like Amazon, will take notice of every single data point, and eventually build out a private and comprehensive infrastructure on Earth and in space. But it doesn’t act like a Silicon Valley startup--reflecting its founder’s values instead. It may all work out one day.

What’s missing, however, is the framework for the space industry “code.” This is the other advantage the tech-sector enjoys--a common framework to work in and become successful with whether it’s HTML, javascript, or some other coding language. What is the common language framework for a space startup?

This is a problem that began before space startups became involved. Some people seem to think that international law is the code. Others believe complying with the mishmash of regulations stemming from various governmental gatekeepers is the code. But what is the “lingua franca” that should be used? What levels the playing field to allow a person to become successful in the space industry?

In this case, this analysis presents questions that I have no answers to. I am not sure anyone does (I haven’t happened upon it during my internet trawls). But it seems to me to be a fundamental question for space startups to be asking--otherwise, each one is in its own vertical, its own home-brewed echo-chamber.