Lilium and the Limits of Ambition: What the eVTOL Pioneer’s Fall Teaches Systems Engineers

In October 2023, Lilium GmbH filed for insolvency. The German eVTOL developer — founded in 2015, once valued at approximately $3 billion following its SPAC listing, and the creator of one of the most architecturally distinctive electric aircraft ever to leave the ground — ran out of runway before the Lilium Jet ran out of development problems.

The post-mortems came quickly, most of them focused on the SPAC valuation mechanism, the failed German government bridge loan, or the broader eVTOL funding winter. Those analyses are not wrong, but they are incomplete. The deeper lessons from Lilium are engineering lessons. They concern what happens when a program’s technical architecture is genuinely novel, when the assumptions that architecture depends on do not materialize, and when the systems engineering process is not mature enough to surface that mismatch early enough to act on it.

A subsequent acquisition of Lilium’s assets by a consortium including Mobile Alpen and the relaunch of operations under Lilium GmbH’s successor entity has kept the program nominally alive. But the original program’s arc — from founding through the first jet-lift demonstrator flights to insolvency — is now complete enough to analyze honestly.

What Lilium Was Actually Building

Most eVTOL concepts in the current generation follow one of two basic lift strategies: multirotor (many propellers generating direct lift, like a scaled-up drone) or lift-plus-cruise (separate propulsion systems for vertical and forward flight). Lilium chose neither.

The Lilium Jet used distributed electric jet propulsion — specifically, 36 electric ducted fans embedded in the leading edges and canards of a fixed-wing airframe. In hover, these fans vector downward to generate lift. In cruise, they rotate to generate forward thrust while the wing generates lift conventionally. There are no exposed rotors. There is no separate lift system. The same 36 motors do both jobs, reconfigured in-flight through flap-like thrust vectoring.

This architecture had genuine appeal. Distributed jet-lift is aerodynamically cleaner than exposed rotors at cruise speeds, potentially enabling higher cruise efficiency and lower noise signatures than multirotor competitors. By eliminating mechanical transmission systems and complex gearboxes, Lilium also reduced one class of failure modes that plague conventional rotorcraft.

But the architecture traded those eliminated complexities for new ones, and the new ones proved more difficult to manage than the program initially modeled.

The Battery Problem Was Structural, Not Incidental

Electric aviation’s fundamental constraint is energy density. Jet fuel contains approximately 12,000 Wh/kg of energy. Current lithium-ion cells deliver roughly 250-300 Wh/kg at the cell level, falling to 150-200 Wh/kg at the pack level after structural, thermal management, and BMS mass is accounted for. That gap — nearly two orders of magnitude — is not a manufacturing quality problem. It is electrochemistry.

When Lilium’s founding engineers developed their architecture and performance models in 2015-2017, they were working from battery roadmaps that projected continued aggressive improvement in energy density. Those roadmaps, from cell manufacturers and independent analysts alike, projected pack-level energy densities approaching 350-400 Wh/kg by the early 2020s.

That improvement did not materialize at that rate. Industry-wide, battery energy density improvement has continued, but at roughly 5-8% per year — meaningful, but far slower than the projections that informed early eVTOL business cases. The Lilium Jet’s range and payload specifications were contingent on battery performance that the market did not deliver on the program’s schedule.

This created a cascading problem. A shortfall in energy density means either reduced range, reduced payload, increased vehicle weight (more batteries to compensate), or some combination of all three. Each of those adjustments has certification implications, structural implications, and commercial implications. The harder question — the one systems engineering process should force a program to answer explicitly — is: at what point does the performance shortfall require not an adjustment to the design, but a reassessment of the architecture itself?

There is no evidence that Lilium’s program formally resolved that question. The public record suggests the program continued optimizing around the battery constraint rather than escalating it to an architectural decision point. That is the kind of deferred decision that accumulates silently in a requirements database — or, more dangerously, does not appear in a requirements database at all.

Thirty-Six Engines and the Requirements Complexity That Follows

Managing a single novel propulsion system through aviation certification is a substantial undertaking. Lilium was managing 36 of them, simultaneously, in an architecture where their interactions were load-bearing to the aircraft’s fundamental flight envelope.

Consider what that means for requirements. Each electric ducted fan unit has functional requirements (thrust at specified power input), performance requirements (efficiency across the flight envelope), safety requirements (behavior on failure), and interface requirements (electrical, thermal, structural, and control connections to the airframe and flight management system). For 36 units, those requirements multiply — but they do not merely multiply by 36. The interdependencies between units mean that the failure mode of unit 17 cannot be analyzed in isolation from units 16, 18, and however many others share its bus segment, thermal zone, or flight control authority.

Fault tree analysis for a distributed propulsion system of this type requires modeling interaction effects at a scale that strains traditional document-based requirements management. A failure modes and effects analysis (FMEA) that does not capture the graph of dependencies between propulsion units, their power management systems, and the flight control architecture is not a complete FMEA. It is a snapshot of individual components that misses the emergent failure modes that regulators — correctly — care most about.

The European Union Aviation Safety Agency (EASA) was developing its Special Condition for small-category VTOL aircraft (SC-VTOL) in parallel with Lilium’s development program. SC-VTOL, finalized in 2019 and refined subsequently, was written partly in response to architectures like Lilium’s — architectures where the novel propulsion approach does not map cleanly onto existing Part 23 or Part 27 rotorcraft frameworks. Working under a novel regulatory framework while building a novel architecture, with requirements that could not be fully locked down until the regulatory framework stabilized, created a compounding uncertainty that the program was not structured to absorb.

Certification Timelines Are Not Project Management Variables

Lilium’s investor presentations projected commercial service entry in 2024-2025. This was not unique to Lilium — most first-generation eVTOL developers made comparable projections in the 2018-2020 period. All of them were optimistic. Most have since revised. Lilium ran out of capital before it could revise.

The optimism was not dishonesty, but it reflected a misunderstanding of how aviation certification timelines work. In software or consumer hardware, timeline is primarily a function of resources: more engineers, faster development. Aviation certification does not work this way. Type certification timelines are governed by the accumulation of safety evidence — flight test data, analysis, ground testing, software qualification — at a rate that the regulator can review, and that the aircraft’s operating hours can generate. You cannot accelerate the accumulation of 1,500 hours of flight test data by hiring more engineers. You can run more test aircraft in parallel, but that option requires capital that eVTOL developers were raising in tranches contingent on development milestones.

For a novel aircraft type operating under a novel regulatory framework, there is an additional timeline driver: regulatory precedent does not exist. EASA and FAA certification engineers are making novel safety determinations for propulsion architectures they have never evaluated. That process involves internal review cycles, requests for additional analysis, and occasionally fundamental questions about whether a proposed compliance method is acceptable at all. Those cycles take time that cannot be purchased.

Lilium’s program trajectory — raising capital against a 2024-2025 service date, with battery performance that did not match projections and a certification framework that was still being defined — created a capital consumption rate that the development timeline could not justify. The program needed more time. It did not have the capital structure to buy it.

What Process Maturity Would Have Changed

This is speculative, but necessary. The question is not whether Lilium should have been built — the distributed jet-lift architecture represents a genuine technical hypothesis worth testing. The question is whether a more mature systems engineering process would have changed the outcome.

A mature process would have done several things. First, it would have made battery energy density assumptions explicit, traceable, and periodically reviewed against actual cell manufacturer data. The assumption would have appeared as a parameter in the requirements structure, linked to the performance specifications that depended on it. When cell roadmaps diverged from projections, the system would have surfaced which requirements were at risk — not as a discovery, but as a managed update.

Second, it would have characterized the propulsion architecture’s complexity in a form that supported regulator communication. EASA’s certification engineers needed to understand how 36 interdependent propulsion units behaved as a system, not as 36 individual units. A graph-based model of the propulsion architecture — capturing dependencies, failure propagation paths, and control authority relationships — would have been more useful than a document hierarchy, both for internal analysis and for regulator review.

Third, it would have formally tracked certification milestone dependencies. When a regulatory framework is under development in parallel with a vehicle, assumptions about what the framework will require need to be tracked as assumptions — with explicit review triggers when those assumptions are invalidated by framework changes. Programs that treat certification requirements as stable when they are not will consistently misestimate the work remaining.

Modern requirements management approaches, including graph-based tools that model system elements and their relationships rather than just storing requirement text, make these practices operationally realistic in ways that earlier document-based tools did not. The industry has matured considerably since the 2015-2018 period when Lilium’s process foundations were established.

What the eVTOL Industry Should Take Forward

Lilium’s insolvency does not indict the eVTOL concept. It indicts a specific combination of architectural novelty, unvalidated assumptions, and process maturity operating under severe capital constraints.

The architectures that survive to certification — Joby Aviation’s tiltrotor configuration, Archer’s lift-plus-cruise, Wisk’s autonomous approach — are not necessarily technically superior to Lilium’s distributed jet concept. They are being built by programs that have, to varying degrees, learned to calibrate ambition against certification reality: locking down architectural assumptions earlier, building regulatory relationships more deliberately, and managing requirements in ways that surface risk before it becomes crisis.

The Lilium Jet flew. The demonstrator vehicle achieved jet-lift flight and transitioned between hover and cruise modes. The fundamental aerodynamic hypothesis was not wrong. What failed was the organizational and process infrastructure required to take a novel, complex aircraft through the full certification gauntlet on a timeline that capital markets would fund.

That is, ultimately, a systems engineering story. The aircraft existed. The engineering process to manage it to certification, at the rate the program needed, did not fully exist alongside it.

Ambition is not the lesson to walk away from. The lesson is that ambition without traceable assumptions, explicit risk management, and process maturity calibrated to the complexity of the system being built will find its limits — sometimes spectacularly, and usually expensively.

Lilium found those limits. The rest of the industry is still learning where theirs are.