Beta Technologies: Electric Aviation’s Quiet Engineer

Most electric aviation companies talk loudly about disrupting flight. Beta Technologies, based in Burlington, Vermont, mostly just builds things. They have logged more electric aircraft flight hours than any other eVTOL company in North America. They have paying customers—UPS, Blade, United Therapeutics—who are not paying for promises. They have a charging network expanding across the country. And they have done most of this without becoming a household name.

That relative quiet is not accidental. It reflects an engineering culture that prioritizes flight-ready hardware over funding-round narratives. It also reflects a certification strategy sophisticated enough to deserve serious analysis, because Beta is attempting something technically harder than most of their competitors realize.

The Dual-Platform Bet

The electric aviation field broke early into two camps: companies pursuing eVTOL, chasing the urban air mobility opportunity, and companies pursuing conventional electric aircraft, targeting cargo and short-haul routes already served by small piston planes. Beta decided both camps were thinking too narrowly.

The ALIA CTOL (Conventional Takeoff and Landing) and ALIA VTOL platforms share a fundamental design lineage. The CTOL variant—the one that has logged most of Beta’s flight hours—operates under Part 23, the FAA’s general aviation certification standard. Part 23 is well understood. Certification pathways are established. The rules are not perfect, but regulators and applicants both know what “done” looks like.

The VTOL variant targets the FAA’s new Special Federal Aviation Regulation 21H and the emerging powered-lift category rules. These rules are still being written in meaningful ways. The certification timeline for any eVTOL company is genuinely uncertain, not because of technical failure but because regulatory frameworks are being invented in parallel with the aircraft.

Beta’s strategy threads both needles simultaneously. The CTOL aircraft generates revenue, validates the propulsion and battery system, accumulates maintenance data, and builds the FAA relationship—all while the VTOL certification process runs on its longer timeline. This is not hedging in the pejorative sense. It is sequenced risk management.

The tradeoff is engineering complexity. Running two active certification programs against a shared platform is not twice the work—it is substantially more, because every shared component now carries requirements from two regulatory frameworks, two operational contexts, and two customer sets that do not always want the same things.

What “Common Platform” Actually Means

Beta’s marketing describes ALIA as a platform. That word does real work here, but it also obscures some difficulty.

The propulsion architecture is genuinely shared. Both variants use the same battery pack format, the same charging interface, and a related motor design. This matters for manufacturing economics and for the charging network: Beta can build one charger standard that serves both aircraft, which is how you actually deploy infrastructure at meaningful scale.

The airframe, however, diverges significantly. The CTOL has a fixed wing, a pusher propeller configuration, and landing gear appropriate to a runway. The VTOL has distributed electric propulsion across multiple rotors, a different structural load path, and an entirely different failure mode profile. The wing itself—a distinctive arched design that appears on both variants—is one of the more visible expressions of shared DNA, but even that wing serves different primary functions in each configuration.

For requirements management, this creates a specific and painful problem: requirements that apply to shared components, requirements that apply only to one variant, and requirements that interact across the boundary. A change to the battery management system architecture might be driven by CTOL operational data, but it carries immediate implications for VTOL certification compliance. A change to the charging interface might be driven by infrastructure deployment logistics, but it affects both aircraft electrical system requirements.

Document-based requirements management—the kind practiced in IBM DOORS or in an elaborate set of Word files—handles this through configuration management conventions: labeling, baseline locking, change boards. Those mechanisms work. They also generate significant overhead and are prone to the classic problem where a change gets made in one document and the downstream implications in three other documents get discovered six months later in a review.

The more tractable approach is a connected, graph-based requirements model where a change to a shared requirement propagates its traceability links immediately, making it visible which variant-specific requirements are potentially affected. That is not how most aerospace programs work today, but it is increasingly how modern AI-native tools implement requirements management for exactly these multi-configuration scenarios.

The Charging Infrastructure Problem

Beta’s charging network—called BEAM, for Beta Energy Access and Management—is the part of their business model that most competitors have not seriously attempted. By mid-2026, they have chargers operating at dozens of sites across North America, with more in deployment.

This is strategically brilliant and technically demanding in ways that are easy to underestimate.

An aircraft charger is not a car charger scaled up. The charging interface must meet aircraft airworthiness requirements, not just electrical code. The power delivery profile has to be validated against the specific battery system in the aircraft. The communication protocol between charger and aircraft is part of the certified aircraft design, which means changes to the charging protocol are changes to the aircraft from a certification perspective.

This creates a requirements coupling that most systems engineering analyses would treat as an interface. In practice, it is tighter than a typical interface. When Beta updates the battery management firmware on the aircraft, they need to validate that update against every charger configuration currently deployed. When they expand the charger’s power output capability, they need to assess whether that expansion is within the validated envelope for the aircraft’s electrical architecture.

The charging network is, in effect, a distributed ground-support system with certification-adjacent requirements. It does not have its own airworthiness certificate. But the aircraft that depends on it does, and the aircraft’s certification assumptions include specific charging behavior. That coupling has to be managed explicitly, or it generates exactly the kind of late-cycle surprise that kills schedules.

Beta’s apparent approach is to keep the charging hardware and software under engineering control rather than treating it as a commodity vendor product. That is the right instinct. It also means the requirements engineering problem extends beyond the aircraft programs into the infrastructure program, and the linkages between them have to be maintained across multiple concurrent development cycles.

Certification Sequencing as Strategy

The FAA’s powered-lift category rules have moved significantly since 2023, but they are still not fully resolved for all operational scenarios. Urban air mobility operations—the use case most eVTOL companies have been building toward—require not just aircraft certification but operating rules, air traffic management integration, and vertiport standards that are still being developed.

Beta’s CTOL certification under Part 23 sidesteps most of this complexity. The ALIA CTOL can fly today, under current rules, to airports that already exist, carrying cargo that customers already want to move. The certification path is complete. The market is real, if smaller than the urban air mobility vision.

This gives Beta something almost no other eVTOL company has: a product that generates engineering learning and revenue simultaneously. Every flight hour on the CTOL program is data on propulsion system reliability, battery degradation rates, and maintenance intervals—data that directly informs the VTOL certification effort. This is not incidental. It is a deliberate way to compress the uncertainty in the VTOL program by running a predecessor fleet.

The risk in this strategy is configuration drift. If the CTOL and VTOL programs evolve separately for long enough, the “common platform” becomes a historical artifact and the economies of scale disappear. Beta’s engineering discipline has to hold the two programs together at the architecture level even as the variants diverge at the system level.

That is a requirements traceability problem at its core. The shared architectural decisions—battery format, charging interface, motor family—need to be maintained as explicit design constraints with clear ownership. If those constraints are implicit, they will be violated by accident. If they are buried in documents, they will be violated by omission. Making them visible and enforced requires tooling that treats the platform architecture as a live artifact, not a baseline document.

What Beta Gets Right That Others Miss

Several things about Beta’s engineering approach stand out against the broader eVTOL field.

They flew before they certified. Beta accumulated substantial flight hours under experimental certification—legal, but not commercially operational—before pursuing type certification. This is how you find the problems that models don’t predict.

They built infrastructure as a product. Most competitors treat charging as someone else’s problem. Beta recognized early that the aircraft and the charging network are a system, and that system has to be engineered as a whole. This is good systems thinking, and it is visible in how they have structured the BEAM program.

They chose customers before scale. UPS is a sophisticated logistics operator. United Therapeutics is a pharmaceutical company with demanding cold-chain requirements. These are not customers who buy vaporware. The fact that they are operating ALIA aircraft tells you something about where the program actually is.

They have not over-raised. By the standards of their sector, Beta has been relatively capital-efficient. This matters because it creates engineering incentive alignment: you do not burn money on speculative features when your runway is finite.

The Honest Complexity

None of this means Beta’s path is smooth. Running two active certification programs simultaneously is a significant engineering management challenge. The FAA relationship has to be maintained across both programs without the regulatory affairs team becoming a bottleneck. The charging network has to expand without outrunning the technical validation of the expanded configuration.

The multi-configuration requirements problem is real and gets harder as both aircraft programs mature. Configuration management under document-based processes works, but it creates overhead that compounds as the design matures and changes become more frequent. Programs that have moved to graph-based, AI-assisted requirements tools—tools like Flow Engineering, which is designed specifically for the kind of multi-system, multi-configuration traceability Beta faces—report meaningfully lower overhead for impact analysis and change propagation. Beta has not publicly described their internal tooling, but the complexity of their requirements landscape makes this category of problem worth watching as the VTOL program moves toward certification.

The broader certification timeline for VTOL remains the largest variable outside Beta’s control. They have managed that uncertainty better than most by building a parallel revenue-generating program. But at some point, the VTOL certification has to close, and the timeline for that depends partly on FAA resources and regulatory clarity that no engineering discipline can accelerate.

Honest Assessment

Beta Technologies is the most technically credible company in the electric aviation sector. That is not a low bar—there are serious engineering teams at Joby, Archer, and Wisk—but Beta’s combination of flight hours, real customers, dual-platform strategy, and infrastructure investment puts them in a different position than companies still primarily in simulation and prototype cycles.

Their dual-platform certification strategy is genuinely clever and has already paid dividends in revenue and learning. The ALIA CTOL is not a consolation prize—it is a working product that funds and informs the harder VTOL program.

The complexity they are managing—shared platform requirements across two certification standards, charging infrastructure coupled to aircraft airworthiness, two concurrent customer programs with different operational demands—is real. The question is not whether they can handle it technically. They have demonstrated they can. The question is whether their requirements engineering and configuration management processes will scale as both programs simultaneously mature toward the parts of certification that generate the most change activity.

That is a problem Beta shares with every serious aerospace program. The companies that solve it with modern tooling will have an advantage in certification velocity that compounds over time. Based on their engineering track record so far, it would be surprising if Beta were not paying attention to exactly that.