After 10 years of building autonomous technologies at the edge, from medical devices for diagnosis and prevention of sleep disorders, to automotive modeling of battery forecasting, to operational and delivery UAVs, I have witnessed teams and organizations struggle with opposing forces of business scaling urges and reliability needs of these technologies.
Autonomous technologies, especially those deployed in operational businesses are notoriously difficult and subject to tight regulations. In this article, we will dive into why scaling autonomous technologies is so difficult, how reliability is a big part of that effort, and how to mitigate those two opposing forces.
Image: 3D UAV Drone Model. Source -- 3Dcadbrowser.com
The Nature of Scaling in Operational Autonomous Systems
Autonomous Operational Systems Are Not Easily Abstracted
The fundamental complexity in most autonomous systems comes from a unique vertical integration across hardware, embedded and software. Unlike pure software platforms, these systems have to contend with physical heterogeneity: diverse geographies, regulatory environments, infrastructure constraints, and user needs. By comparison, traditional horizontally integrated software enterprise businesses can leverage concepts such as abstraction, generalization, and modularity, which are less effective in hardware-software autonomous technologies.
In software, abstraction allows engineers to separate concerns, encapsulate complexity, and build composable systems fast. However, in hardware-linked systems, heterogeneity is present in the many differences in power conditions, mechanical tolerances, or atmospheric conditions, etc.
Subdivisibility: Why Software is Easier
Software benefits from what the technical community might call the subdivisibility property. Systems can be decomposed into microservices, APIs, or modules, each independently testable, upgradable, deployable and version-controlled. This enables massive horizontal scaling with relatively little marginal cost.
By contrast, hardware systems are not easily subdivisible. Their complexity emerges from tightly coupled physical interactions. A faulty propeller design cannot be “patched” in real-time; it requires physical replacement, retesting, and downstream design revalidation.
The Nature of Scaling in Hardware
Why Hardware Is Hard
Testing and deploying hardware involves significantly more friction than software. Simulation fidelity is often limited, iteration cycles are longer, and real-world deployments are costly. The analog of dependency injection in software—injecting alternate behaviors or mocks—is poorly developed in hardware.
Even in vertically integrated startups, delays to customer launch often stem from hardware bottlenecks. Prototyping constraints, supplier variability, and physical failure modes resist the repeatable, scalable practices of software deployment.
Emerging Acceleration Methods
Hardware systems have seen significant improvement in reduction of the iteration cycles in recent years. Innovations like 3D printing (FDM, SLA, SLS), and AI-driven generative design have shown promise in modeling prototypes, manipulating and combining parts, and simulating them within a system. Companies like Markforged or Backflip are pushing the envelope on rapid prototyping, automated testing, and hardware-in-the-loop simulation. Unlike software, hardware-in-the-loop is slow to distribute and disseminate, as most experiments and prototypes are contained in the physical spaces of labs and test sites. Thus, much remains to be done to close the loop between fast prototyping and robust system integration.
Integration Challenges: Software-Hardware Entanglement
Tightly Coupled Systems Resist Isolation
The vertical integration of operational autonomy demands deep coupling between perception systems, control logic, actuators, embedded boards, and cloud-based infrastructure. Failures are rarely localized—when a system fails, root causes may span the physical and logical stack.
A UAV, for instance, must integrate propulsion, navigation, wireless comms, safety constraints, and customer-facing apps. Each component’s behavior influences system-wide reliability. Traditional modularity breaks down under safety-critical requirements. Simulation testing generally covers up from user apps to comms, but vehicle testing scenarios are 90% performed in real-flight testing. Just setting up a single testing mission requires full E2E coordination.
The Vicious Cycle of Real-life Testing
As autonomous systems are strictly governed, most of the time systems requirements and constraints are directly dictated by regulatory frameworks, certifications and vehicle capabilities. The more autonomous technologies are operated, the less risky they become, hence, the more room there is for scaling operations. This explains why emerging autonomous technologies operate for a long time in a geo-fenced area, before they are able to expand significantly. Waymo is an example of an autonomous driving technology which started first operations in a 4,900 m2 area in suburban Michigan, then expanded to a limited area of San Francisco, with initially assisted then fully autonomous operations. That allowed the company to learn the service geographies, constantly iterate on safety metrics and gradually improve their reliability while staying conservative on scaling. On the other hand, Cruise, its competitor, started public operations in San Francisco in February 2022 and aimed to expand to 4 major cities in 7 months, before shutting down because of a fatal crash.
 |
 |
Image: Waymo (left) and Cruise (right) Service Areas in San Francisco. Source - Waymo & Cruise
Something I would call a “vicious cycle” of E2E testing limits the pace at which autonomous technologies can “afford” to scale while not compromising significantly on reliability. As such, the longer the company can perform testing the more room it has to scale its operations. Any system failure is a huge step back and potentially a devastating outcome, so companies operating these technologies need to be very sensitive to how far they push their safety guardrails.
Image: E2E Scale Testing Cycle of Autonomous Systems.
The cycle of E2E scale testing can be represented in three stages, as shown above. Breaking this cycle requires better test harnesses, higher-fidelity simulations, and composable safety validation strategies across systems and Line Replaceable Units (LRUs).
The Role of Regulation
Compounding the challenge is a stringent and evolving regulatory landscape. Autonomous systems—especially those operating in public spaces—must comply with national and international safety standards. These introduce friction in iteration cycles, deployment, system capabilities and data collection. Unlike consumer software, where A/B testing is trivial, autonomous technologies often face multi-month certification timelines between revisions.
A strong legal and certification team can pitch and report exhaustively on the systems evolving capabilities to the certifying authorities. However, it is still the burden of the organization to convince these authorities that their systems are at least as capable as a human, since much of the regulation is retroactively referencing precedents of manned equivalent technologies. For instance, in the drone space, the FAA and civil aviation regulates UAVs on Parts 107, 135, etc, which were initially reserved for manned commercial aircraft. New UAV systems, especially if cutting-edge, must be provably safe, explainable, and fail-safe under known conditions and scenarios. The good news is that developers of these technologies have a lot of leeway in setting certification precedents and be creative about their design and implementation.
Exceptional Talent and System Level Thinking
The future of autonomous technologies will be shaped not just by better algorithms or faster chips, but by teams that understand the full stack and how systems interact with each other - from propellers to user interfaces. Engineering leaders and organizations must invest in:
- Setting unified directions across the entire engineering vertical. Even if the stack can be pieced together in parts, the technical vision should be unifying across.
- Cross-disciplinary collaboration (mechatronics, ML, embedded systems, cloud infra)
- Tooling that enables better hardware/software co-simulation
- Regulatory fluency that enables safe deployment without paralyzing iteration cycles and building consumer trust
Scaling safely in autonomous systems is not just a technical challenge—it’s a systems level problem in uncharted spaces. As companies and organizations are building innovative and disruptive technologies, they should also keep an eye on product market fit, consumer demand and all the other “non-technical” but business-fundamentals that can make or break an otherwise technically brilliant organization.
For questions, domain knowledge or sharing ideas, reach out to me at https://www.adrianarotaru.com/.
