The misunderstanding comes from a flawed assumption: that iteration means “just do stuff and see what happens.” It doesn't. Iteration means taking calculated risks early in development to achieve a higher safety at production faster and with lower cost.

Each step is planned to work the first time—though the program as a whole might not work perfectly at first.

Even teams that take an agile approach fall into a common trap when designing safety-critical systems: They assume they need to design everything perfectly from the start.

This assumption is understandable. When people look at the process and rigour needed when going from Crew Dragon V3 to V4, they assume the same level of detail existed in Dragon V1. It didn’t.

The Evolution of a Certified Product

Most teams developing safety-critical systems follow a structured, iterative approach. The journey from early prototype to a fully certified product typically follows a six-phase evolution:

V0 – Concept Model

Looks good for investors but doesn’t work. This is where early feasibility studies happen. No real hardware is tested yet.

Tech Demo – Proving It’s Real

A rough, working version of the system to show viability. Think of Starhopper for Starship—just enough functionality to prove basic engineering concepts.

Integrated Iterations (V1, V1.1, V1.2, etc.)

The core system is continuously improved and refined. Each iteration adds more fidelity, testing more capabilities while still avoiding unnecessary complexity.

Complete System Prototype

A near-final, but still evolving, version of the system. This is when the hardest integration challenges start getting solved.

Real Product

The version you take to certification authorities like the FAA or EASA. It’s functionally complete but may not yet be flyable or fully validated.

Certified Product

The final, production-ready system that meets all regulatory and operational requirements. By this time you may have 10,000+ requirements. That doesn’t mean you should start with 10,000.

They start with just a handful, testing basic functionality and refining requirements as they learn. This approach ensures that complexity grows naturally, rather than being forced prematurely.

The Danger of Overloading Requirements Too Early

Starting with a fully detailed, regulation-heavy design from day one can lead to massive inefficiencies and increased risk:

Locks in assumptions too early – You end up designing for constraints that might change as you test real-world performance.

Slows down iteration – Complex requirements create administrative bottlenecks, delaying testing and validation.

Increases costs without added safety – Teams spend resources verifying elements that might not even make it into the final system.

Instead, teams should prioritize design criteria over exhaustive requirements in early development. A handful of core metrics—such as “does it generate thrust?”, “does it power on/off?”—are enough to guide the first versions.

Regulations Should Guide, Not Dictate, Design

The biggest mistake? Designing backward from regulations.

Teams that take FAA, NASA, or EASA certification documents and use them as a blueprint for development will have a very hard time.

Certification documents exist to evaluate a finished design, not to dictate how it should be created. Engineers should focus on developing a system that works first—then apply regulatory requirements as a validation framework.

Certification docs from the FAA don’t design aircraft.

Safety-critical systems must be built with rigor, but that doesn’t mean front-loading complexity. The best teams start small, test aggressively, and scale complexity only when needed.

Instead of asking, “How do we design something that meets regulations from day one?” teams should be asking, “How do we design something that works safely and iteratively prove its reliability?”

Agile does work for safety-critical systems. In fact, it’s the only approach that consistently produces safe, innovative, and cost-effective results.