Regulation is a design constraint, not a deployment problem

The building-code mistake

The paper opens the chapter with the mental model most technical founders actually use: regulation as a building code. A set of rules you check the design against once it is mostly done, with a lawyer for the corner cases. That works in industries whose rules were settled before the company existed.

It fails fastest in exactly the categories where the most interesting companies are being built. Autonomous aircraft, in-space servicing, hypersonic transport and on-orbit manufacturing all lack a complete regulatory framework — the rules either do not exist yet, exist in pieces across bodies that do not coordinate, or exist in a form written for a different kind of system and make no sense applied to the new one. On top sits a separate layer of operational compliance — export control, cybersecurity certification, quality management, ownership rules — that applies whether or not the main framework has caught up.

The authors' formulation of the split is the part to internalise: "Founders who treat this as a deployment problem — build the product, get it certified, then add compliance on top — are the ones whose products don't deploy. Founders who treat it as a design constraint, letting the regulatory and compliance picture shape what the product is, where it is built, and how the company is structured, are the ones who reach scale." And the difference is not lobbying skill. It is when the regulatory work starts, because by the time the system is designed and the cap table has closed, "the biggest regulatory decisions have already been made, silently, by the engineers and founders, in choices that did not feel regulatory at the time."

Standards bodies are upstream of regulators

Here is the lever. Regulators move slowly on novel systems less because they are cautious or short-staffed — though the paper grants both are partly true — than because they can certify only against existing standards. And they largely do not write those standards. The FAA does not write airworthiness standards from scratch; it adapts work from RTCA, the consensus body behind most US civil aviation standards since the 1930s. EASA does the same with EUROCAE. ICAO sets the international floor. In space, on-orbit servicing, debris removal and in-space manufacturing all wait on standards bodies before regulators can authorise anything.

So the complaint gets rewritten: "When a founder complains that the FAA will not certify their autonomous vehicle, the truer complaint is that RTCA has not produced the standard the FAA would certify against."

Why that matters commercially: standards committees do not write rules on demand for a single company, but their committees are open to industry "in ways most founders don't realise and almost none use." The paper's example is RTCA Special Committee 228, which produces the detect-and-avoid and command-and-control link standards that will decide when large uncrewed aircraft can fly in controlled airspace. It has met quarterly for more than a decade. The companies that put senior engineering time into it — the primes plus a few well-funded startups — shaped the standard around their own designs. The companies that did not "inherit standards built for someone else's system."

That is the mechanism. Now the European version of the room list, which the paper does not provide because it is not writing for us:

Add one European-specific layer with no US equivalent: the EU Space Act as it takes shape, which proposes to bring space activity authorisation, resilience and debris rules into a single EU-level framework, on top of the national space-activity laws that currently do that job member state by member state. If your product is in a category that framework will touch, the drafting period is precisely the window the paper is describing — the moment when engagement is cheap and the outcome is not yet fixed.

The regulator is plural, and most founders know one of them

The paper's second observation is that founders usually find one regulator and assume it is the whole surface. In the US a commercial space company answers to the FAA for launch and reentry licensing, the FCC for spectrum and satellite authorisation, NOAA for commercial remote sensing, the Bureau of Industry and Security for dual-use export control, the State Department for ITAR-controlled defence articles, and the relevant defence components for anything defence-adjacent — plus state-level spaceport authorities in Texas, California, Florida, Colorado, New Mexico and Virginia. "A founder who wants to deploy in three jurisdictions usually runs three certification programs at once, with three evidence packages and three inspection regimes. Primes amortise this across global programmes; startups pay it as a fixed cost on a smaller revenue base."

The European surface is differently shaped, and in one respect harder: there is no single federal authorisation. For a European space company the list typically includes:

• A national space-activity authorisation — the licence to conduct space activity at all, granted under the national space law of your member state, with its own liability and insurance conditions. This is the layer with no US analogue at the state level, and the one most easily missed by teams who assume "Europe" is one jurisdiction.
• Your national spectrum regulator, which files on your behalf into the ITU. Filings have queues and deadlines that do not care about your funding round.
• EUSPA and the European Commission for programme-level rules where you are inside the EU Space Programme, and EASA where you cross into aviation.
• EU dual-use export control under Regulation 2021/821, administered by national licensing authorities — the European counterpart to the paper's EAR discussion.
• NIS2 for cybersecurity obligations, where you fall in scope, plus programme-specific security requirements when working with ESA or on EU space-security lines.
• Data protection, which is not the single regime founders assume: as we covered in the legal primer for space startups, ESA runs its own data-protection rules rather than being bound directly by the GDPR, and both ESA and EUSPA write privacy provisions into their contracts.

And ITAR still reaches you. It is US law, so a European company is not subject to it the way a US company is — but ITAR-controlled US-origin components carry re-export and retransfer restrictions with them, constraining who may touch the technical data and where the resulting system can be sold. That is the whole reason "ITAR-free" became a European design goal rather than a marketing slogan. It is a bill-of-materials decision, made in year one, that determines which customers you can serve in year four. Exactly the paper's point about choices that do not feel regulatory at the time.

Compliance overhead, and the moat it turns into

The paper is careful not to moralise about the compliance stack, and its cost figures are worth quoting because they are the kind of number founders never model. In the US the load includes ITAR, EAR, NDAA §889 supply-chain restrictions running several tiers down, DFARS cybersecurity requirements, AS9100 quality management, FedRAMP for cloud services touching federal data, and CMMC 2.0 third-party certification with audit costs of $100K–$200K for Level 2 and $300K–$500K for Level 3 at small-company scale. "The combined load is most of a senior compliance lead's full-time job from the first defense contract on, and that cost barely shrinks for a smaller company."

The observation that follows is the one that changes behaviour: the same burden that falls hardest on startups is, once built, a moat a competitor with the same funding cannot rebuild within eighteen months. Certifications, a mature export-control programme, a cleared workforce — "a position the next entrant cannot buy with a check." Hence: "Founders who build for the moat beat founders who build to dodge the cost, because the cost gets paid either way."

And the timing asymmetry: a founder who hires a compliance lead before the first defence contract closes pays for capability they will not use for twelve months. A founder who waits until the contract closes pays twice — once to retrofit under audit pressure, once for the delay the retrofit adds to the customer relationship. The first is much more capital-efficient. The second is what most founders do, "because the first feels like wasted money in the seed round, when cash is tightest."

One US-specific item deserves a European translation because the underlying trap is identical. FOCI — Foreign Ownership, Control or Influence — determines eligibility for US classified work, and the paper's warning is that with venture capital now global, almost every startup has some exposure, and the fixes cost far more at Series C than at incorporation: "in some categories of work it is no longer possible at all." Europe's version is not called FOCI, but the mechanism exists: ESA and EU security-classified work, national defence programmes and EDF participation all carry ownership, control and clearance conditions, and several member states run foreign-investment screening on top. The founder-facing lesson survives translation exactly — your cap table is a regulatory decision, and the cheapest time to get it right is before the first cheque, not during diligence for the contract that pays for the company.

Regulatory geography is a strategic choice

Most talk of harmonisation assumes the split between regimes is temporary. The paper bets it is not: full harmonisation across the FAA, EASA and the rest "is not coming on any timeline that matters to a founder today", because the incentives, legal traditions and safety cultures are too different. Over fifteen to twenty years it expects agreement on a few high-value items — a shared vocabulary for autonomy levels, mutual recognition of flight-test data, common formats for telemetry and incident reporting, aligned operational design domain definitions — and permanent divergence on anything with strategic content: export control, cybersecurity certification, mission authorisation for novel categories.

Their explanation for why is the most quotable line in the chapter: "International standards are written by people who show up to the working groups, and those who show up represent the institutional interests of the jurisdictions that send them." The paper notes that China currently chairs an outsized share of aerospace-relevant ISO and IEC technical committees and has been deliberate about it for two decades, while the US has "historically punched below its weight", engaging company-by-company rather than through coordinated national policy. Read from Europe, that is not a lament — it is an open door, and ECSS and ISO TC20/SC14 are the doorways.

If fragmentation is permanent, then where you incorporate, test, build and deploy first becomes strategy rather than administration. The paper's own examples make the case that this favours deliberate small-jurisdiction choices: Luxembourg, the UAE, Singapore, Japan, India and Australia each built strong positions in particular niches by pairing clear regulatory paths with capital and infrastructure; the UK's CAA has been ahead of the FAA on commercial drone integration for most of a decade; New Zealand's approach to commercial launch produced Rocket Lab. Its list of founders who made a geography bet is: "Rocket Lab built in New Zealand. Skyroot built in India. ICEYE built in Finland. ICON built in the UAE. Each made a strategic bet on geography that the founders defaulting to El Segundo did not, and each is now extracting value the defaulters cannot replicate."

For a European founder the practical form of that question is narrower and more answerable than it looks: which member state's licensing regime, liability cap and insurance requirement actually fit your mission profile, and does your funding route line up with the same jurisdiction? Those two answers should not be chosen independently, and most teams choose the second one first without noticing they have also chosen the first.

Step changes happen after accidents, and the maths is asymmetric

One more structural point, because it changes how a founder should think about risk work rather than compliance work. Regulation in this sector does not tighten steadily. It moves in step changes, and accidents trigger them: the MAX 8 grounding reset what the FAA expects of certification paperwork across all transport-category aircraft; the Columbia accident reshaped NASA's risk posture for a decade; uncontrolled reentries are slowly producing new international debris rules.

"Every founder pushing hard on the regulatory frontier is quietly betting their company won't be the trigger for the next step change. Most have not priced this bet." And the asymmetry is brutal: a step change triggered by a competitor's accident is a tailwind for companies already held to higher standards. A step change triggered by your accident may end the company, and sometimes the wider market's tolerance for the technology.

What distinguishes survivors is not the absence of failures — SpaceX's early Falcon 1 failures and Blue Origin's uncrewed New Shepard mishap stayed within bounds the public and regulators were prepared to accept. It is the willingness to treat accident scenarios as first-class engineering work, "assuming the company's regulatory future turns on how its worst day is handled, not how its best day is marketed."

A checklist before the architecture is locked

1. Which standards bodies produce the standards that will govern this product, and where are they in their work cycle? If you do not know, someone else is designing your regulatory architecture. Read the position papers, attend one meeting, submit comments on open drafts. For most European space teams that means ECSS first, then ISO TC20/SC14, ITU/WRC for spectrum, and EUROCAE if you touch aviation.
2. Map every regulator with jurisdiction — plural. National space-activity authorisation, national spectrum regulator plus ITU filing, EUSPA or Commission programme rules, EASA if applicable, dual-use export control, NIS2, and the contract-specific data provisions ESA and EUSPA write into their own agreements. Mapping this in year one is cheap. Discovering it in year four is not.
3. Decide the ITAR question at bill-of-materials level. A US-origin controlled component in your design is a re-export restriction on your future customers. Make it a deliberate choice with a named reason, not an accident of the first supplier who answered the email.
4. Check the cap table against the work you want. Ownership, control and clearance conditions attach to ESA and EU security-classified work, national defence programmes and EDF participation. Restructuring at incorporation is cheap; restructuring during contract diligence is not, and in some categories it is no longer possible.
5. Choose the jurisdiction on purpose, and match it to the funding route. Licensing regime, liability cap, insurance requirement, and the agency you will actually sell to. These should be one decision, not two.
6. Write down your worst-day posture, and make it credible. Designing the company so its survival does not depend on never having an accident is a different exercise from designing it to be safe. You need both, and only the first can be done in advance.

None of this removes the regulatory void or the compliance overhead — the paper is clear that both are permanent features of the sector. What the checklist does is turn them from deployment-stage surprises into design-stage constraints, "the only kind of regulatory work that produces companies that can deploy at all."

For the rest of the argument — the four drivers, the servicing regimes, the five predictions with the authors' own counter-arguments — see our European read of the full paper. For the demand-side diagnostics that belong in the same year-one conversation, see Feasibility is not viability. And for what happens to your intellectual property once an ESA or EU contract is signed, the IP-ownership rule every founder gets wrong.

FAQ

Sources