The eVTOL Certification Infrastructure Crisis

Five years ago, the eVTOL industry was racing to prove that electric vertical lift was physically possible. Battery energy density, motor controller efficiency, distributed propulsion stability — these were the hard problems. Hundreds of millions of venture dollars flowed into airframe programs, simulation environments, and subscale demonstrators. Companies hired brilliant aerospace engineers and gave them latitude to move fast.

That era is ending.

The companies that survived the shakeout — Archer, Joby, Lilium’s successor programs, Wisk, Beta Technologies, Overair’s inheritors, and a cohort of less-publicized international efforts — are now confronting a different kind of hard problem. They have to certify.

Type certification under FAA Special Federal Aviation Regulation 110 and EASA Special Condition for VTOL aircraft (SC-VTOL) imposes a documentation, traceability, and process control burden that the venture-backed startup engineering culture was not designed to carry. The aircraft exist. The evidence that the aircraft were designed and built to a controlled, auditable standard — that is what most programs are now scrambling to construct.

This is the eVTOL certification infrastructure crisis: not a crisis of engineering capability, but of engineering process.

What Certification Actually Demands

SFAR 110 and SC-VTOL are not simple rules. They are frameworks that reference substantial portions of existing airworthiness standards — Parts 23 and 27 depending on the applicant’s chosen path — and layer on novel aircraft-specific requirements for energy storage, propulsion redundancy, and flight control architecture. The result is a compliance matrix of substantial complexity.

To satisfy that matrix, an applicant must demonstrate three things. First, that they understand exactly what requirements apply to their aircraft. Second, that for each requirement they have identified an acceptable means of compliance. Third, that all design, analysis, and test activities can be traced from certification requirement through means of compliance to physical evidence — continuously, without gaps.

This is requirements traceability in its most demanding form. A requirement in the certification basis connects to a system requirement, which connects to a subsystem requirement, which connects to a design artifact, which connects to a test procedure, which connects to a test result, which connects back up to compliance closure. Break any link and the chain is open. In a certification audit, open links are findings, and findings delay entry into service.

The engineering organizations that have done this before — the Boeings, Airbuses, and Bell Textron programs of the world — built this infrastructure over decades. They have configuration management systems, requirements databases, document control processes, and DER relationships that reflect fifty years of accumulated compliance practice. eVTOL startups have none of that inheritance.

Four Infrastructure Gaps

The mismatch between startup engineering culture and certification demands shows up most acutely in four areas.

Requirements Management

Venture-backed aerospace startups typically manage requirements the way software companies do: in documents, spreadsheets, or lightweight project tools. A Notion database, a Confluence wiki, a shared drive full of Word files with version numbers in the filename. This works for early design. It fails catastrophically for certification.

The problem is not that the requirements don’t exist. Early-stage programs generate enormous volumes of requirements content — system requirement reviews, preliminary design reviews, hardware and software requirements specifications. The problem is that this content exists in a form that cannot be traced, queried, or audited. When a certification engineer needs to demonstrate that every requirement in the certification basis has been allocated, flowed down, and covered by evidence, a folder of PDFs cannot answer that question. A spreadsheet RTM maintained by one engineer who left the company eighteen months ago cannot answer that question.

Several eVTOL programs have reached Stage 3 or Stage 4 of their certification process only to discover that their requirements baseline is not a baseline at all — it is a pile of documents representing the state of the design at different points in time, with no governing structure and no verified parent-child relationships. Rebuilding that structure retroactively, with a live aircraft design still evolving, is among the most expensive things a certification program can do.

What those programs needed from the beginning — and what the more prepared applicants built early — is a graph-structured requirements database where every requirement has an identifier, an owner, a status, and a set of traced relationships to upstream and downstream artifacts. That structure makes compliance queries answerable and makes design changes impact-traceable. Without it, every change request becomes a manual archaeology project.

Configuration Control

Certification requires that you can identify, at any moment, the exact configuration of the article under review. The drawings, the software, the hardware specifications, the analyses — all of it must correspond to a controlled baseline that the certification authority can inspect and that the manufacturer can reproduce.

eVTOL startups typically reach their demonstrator and prototype phases with robust digital design tools — CATIA, NX, or Onshape for mechanical; Git-based flows for embedded software — but without a configuration management system that governs the relationship between those design artifacts and the physical aircraft. The demonstrator flew. But what flew? At what revision? With which deviations approved by which authority?

This is not a philosophical question during certification. The FAA conformity inspection process requires that every inspection article conform to controlled drawings and that any deviation is documented. Companies that cannot answer conformity questions with precision face conformity findings that stall test programs.

The underlying issue is that configuration control requires a discipline of change management that conflicts with the rapid iteration culture of early development. Engineers who spent three years making rapid design decisions now need to process changes through formal impact assessment, approval, and baseline incorporation. The cultural shift required is significant, and the process infrastructure to support it has to be built under program schedule pressure.

Software Assurance

The majority of eVTOL aircraft are fly-by-wire, with flight critical functions executed by software. That software must be developed to DO-178C, with rigor level determined by the failure condition classification of the function. For functions whose failure could be catastrophic, the applicant must demonstrate Level A compliance.

DO-178C is one of the most demanding software development standards in any industry. It requires that requirements, design, code, and tests are all produced in a controlled, traceable process. Every line of safety-critical code must be covered by structural coverage analysis. Every requirement must be verified. Every tool used in development must be qualified or its outputs independently verified.

Very few eVTOL startups began their software development programs under DO-178C. Most began writing flight control software in Python or C++ using modern software engineering practices — agile sprints, continuous integration, automated testing — that are not inherently DO-178C compatible and require substantial process wrapping to become so.

Retrofitting DO-178C compliance onto an existing codebase is not merely difficult. In many cases it requires rearchitecting the software development process from scratch, rewriting test infrastructure, and in some cases, rewriting the code itself to make its structure amenable to structural coverage analysis. Programs that started this work late are experiencing multi-year delays.

Means of Compliance Development

For novel aircraft, many of the requirements in the certification basis do not have established means of compliance. No one has certified a distributed electric propulsion system under Part 23 before. No one has demonstrated acceptable continued safe flight capability for an aircraft with twelve motors and a lithium-ion battery pack under SFAR 110 before.

The applicant must propose means of compliance and negotiate their acceptance with the certification authority. This is Issue Paper development under the FAA process, or Certification Review Item development under EASA. It is a process that requires deep understanding of the regulatory intent behind each requirement, an ability to propose technically rigorous test or analysis methods, and a relationship with the certification authority built over time.

Startups that have not staffed experienced DERs, Type Certificate holders, or certification program managers struggle here not because their proposals are technically wrong, but because they have not built the institutional relationship and process fluency needed to move proposals through authority review efficiently. Each open Issue Paper represents a certification dependency that cannot be cleared until it is closed.

Building Infrastructure Mid-Program

The uncomfortable reality is that most eVTOL programs are building certification infrastructure while the aircraft is still in active development. This is not unique to eVTOL — it has happened in other novel aircraft programs — but the venture funding model creates particular pressure. Investors funded aircraft development. They are now being asked to fund process remediation. The business case for the process work is harder to tell.

The programs doing this well share several characteristics.

They have hired leaders who treat certification infrastructure as engineering work, not paperwork. The best Chief Engineers at certification-stage eVTOL companies are people who understand that a requirements database is a technical artifact as important as an FEA model — because without it, the FEA model cannot be traced to a certification requirement and cannot generate compliance credit.

They have adopted tooling that connects requirements to design to evidence without requiring manual synchronization. Legacy aerospace tooling — IBM DOORS, Polarion, Jama Connect — offers the structural rigor the certification environment demands, but many of these platforms were designed for large, stable programs with dedicated requirements engineers and IT support organizations. Their configuration overhead can overwhelm a 200-person startup engineering team.

Newer platforms are beginning to address this directly. Flow Engineering, for instance, was built specifically for hardware and systems engineering teams that need certification-grade traceability without the administrative burden of a 1990s-vintage requirements management system. Its graph-based data model treats requirements, design artifacts, test procedures, and compliance evidence as connected nodes — which means that when a design changes, the impact on downstream compliance evidence is immediately visible rather than discovered months later during an internal audit. For eVTOL programs that started with informal requirements practices and are now rationalizing their compliance baseline, this kind of tool offers a path that doesn’t require abandoning the engineering culture that got them to a flying prototype.

They have accepted that the transition to certification process discipline will slow them down for six to eighteen months before it speeds them up. Programs that try to maintain the velocity of early development while simultaneously standing up configuration control, DO-178C processes, and requirements traceability infrastructure typically succeed at neither. The programs that have set realistic expectations with their boards and investors about this transition period are the ones emerging from it with intact certification programs.

What the Industry Is Learning

The collective lesson from the first cohort of eVTOL companies that have reached the middle stages of certification is not subtle: the infrastructure gap was real, it was underestimated, and it is solvable — but only if it is treated as a first-class engineering problem from a point earlier than most programs addressed it.

Several specific lessons are converging across programs.

Requirements must be machine-readable from the start. A requirement that lives in a Word document is a liability in a certification program. It cannot be queried, cannot be traced, and cannot be verified to be current. The cost of moving to a structured requirements management system is high early and catastrophic late.

Configuration control cannot be retrofitted without stopping. The programs that have successfully brought configuration control discipline into active development programs did so by stopping the design, establishing a controlled baseline, and then resuming under change control. Attempting to do this incrementally while design continues has failed repeatedly.

DO-178C needs a dedicated program. It cannot be treated as a property of the software team’s existing practices. It is a separate, parallel process that must be staffed, tooled, and scheduled with the same rigor as the hardware test program.

Means of compliance work is relationship-dependent. The teams with former FAA and EASA staff, or with advisors who have personal relationships at the authority level, move Issue Papers faster. This is a structural advantage that cannot be fully substituted with process.

Where This Leads

The eVTOL programs that receive type certificates in the next five years will not necessarily be the ones with the best aircraft. They will be the ones with the best certification programs — the ones that understood the documentation, traceability, and process rigor demands early enough to build the infrastructure to meet them, and that staffed and tooled those programs accordingly.

The aircraft design problem turned out to be solvable. The engineering infrastructure problem is where the industry will be separated.

That is, in its own way, an encouraging observation. Process problems are fixable. They require investment, discipline, and the willingness to slow down to speed up — but they do not require new physics. The eVTOL companies that can make that cultural transition while maintaining the engineering talent that built their aircraft are the ones that will land on the other side of type certification. The ones that can’t will have built very impressive demonstrators.