Why building frontier tech isn’t about solving equations but surviving uncertainty and skepticism

Developing frontier technology is often framed as a technical challenge, as if the entire endeavor could be reduced to solving a single equation. In my experience, that framing is incomplete and misleading. The real work has very little to do with arriving at one correct answer and far more to do with navigating an environment defined by uncertainty, skepticism, and constant pressure to prove that what you are building should exist at all.

Source: Sebastian Peralta

At one point, I spoke with someone in the industry who told me that what I was trying to build had been attempted many times before, and almost all of those efforts had failed. He didn’t call it impossible, but the message was clear. In robotics, past failures shape expectations. When enough attempts fall short, people stop treating the problem as unsolved and start treating it as unsolvable.

My response was to question the underlying assumptions behind it. I had spent years studying robotics systems, reading open-source code, and working through research that, in my view, pointed to a different approach. The problem was not that the goal was unattainable. It was that the discipline required to pursue it had been underestimated.

That distinction matters. A large number of startup failures, particularly in robotics and other frontier domains, are not simply the result of hard problems. They are the result of inconsistent execution, fragmented thinking, and premature trade-offs. Research shows that 70% of digital transformation initiatives fail to meet their stated objectives. That statistic is frequently discussed in enterprise contexts, but it applies just as directly to frontier innovation. The challenge is to maintain the discipline to develop something properly over time instead of simply creating something new.

In robotics, that discipline manifests in ways that are often invisible from the outside. It requires modeling the real world with an almost obsessive level of precision. It requires making architectural decisions that prioritize long-term adaptability over short-term convenience. And it requires resisting the temptation to introduce brittle shortcuts simply to demonstrate progress.

At the same time, the technical side is only part of the equation. The other half is economic and operational. Building a system that works in isolation is not enough. It has to be deployed, integrated, and sustained in real-world environments. That introduces a second layer of uncertainty, one that cannot be solved purely through engineering.

This is where many teams encounter a different kind of pressure. It is not the pressure of solving a problem, but the pressure of leading through ambiguity. As a founder, I am often asking a team to commit to a direction without having full visibility into the outcome. They do not have the same context I have accumulated over years of study and iteration. What they have is a set of signals, a roadmap, and a level of trust.

Maintaining that trust requires a specific kind of discipline. It is not enough to communicate a vision. You have to demonstrate progress in ways that are tangible, even if they are incremental. You have to show that achieving one capability implies the possibility of achieving a more complex one. Over time, that builds a chain of reasoning that others can follow, even if they cannot yet see the full picture.

Uncertainty, in this context, does not disappear. It remains a constant presence. The goal is to narrow it rather than eliminate it. Every hypothesis we test, every system we deploy, reduces the range of possible outcomes. We move from a broad unknown to a more defined set of possibilities, and then make decisions within that constrained space.   

This approach mirrors how progress often unfolds across the broader economy. Fifty-nine percent of the most confident CEOs said they planned acquisitions within a 12-month horizon, compared to just 16% of the least confident, highlighting how decisive leaders move even in uncertain conditions. That reality does not fade at the frontier. If anything, it becomes more pronounced. In early-stage innovation, there are no established playbooks to rely on, only evolving hypotheses. You are not just operating within a system. You are building the system itself in real time.

Another dimension that is frequently overlooked is the human element. In robotics, there is a tendency to focus on systems as purely mechanical or computational constructs. I take a different view. Some of the most effective technological advances have come from studying how humans learn, adapt, and interact with the world.

There is a reason neural networks are structured the way they are. There is a reason concepts like modularity and state-based reasoning have proven effective. These are not arbitrary design choices. They are reflections of patterns that have already been validated in nature. Following that blueprint is about leveraging a model that has already demonstrated robustness.

In practical terms, that means building systems that can learn from interaction, adapt to new inputs, and operate in ways that align with how humans naturally engage with their environment. It also means recognizing that the most efficient interface is often the one that requires the least change from the user. Technology should conform to human behavior, not the other way around.

The challenge, of course, is that this approach adds another layer of complexity. It requires thinking across disciplines, from software engineering to cognitive modeling to real-world deployment. It requires holding multiple constraints in mind simultaneously and deciding which ones can be adjusted and which ones cannot.

Building frontier technology is not a linear process. It is not a matter of identifying the right formula and executing against it. It is an ongoing exercise in judgment, discipline, and resilience.

There will always be naysayers. Some will be informed, drawing on legitimate patterns of past failure. Others will be reacting to the inherent risk of the unknown. Both perspectives are valuable, but neither should be definitive. If you accept them as final, you stop exploring the possibility that the constraints themselves might be wrong.

The most important lesson I have learned is that constraints are often treated as fixed when they are, in fact, negotiable. If a tool cannot achieve what you need, the default response is to work within its limitations. In frontier work, that is not always the right approach. Sometimes the better path is to build a new tool, one that aligns with the problem rather than forcing the problem to conform to the tool.

That decision requires discipline. It requires resisting the urge to take the easier path. But it is also where the opportunity lies. When you are willing to rethink constraints and invest in building the right foundation, you create the possibility of doing what others could not.

Developing frontier technology requires unwavering commitment to a direction, even when outcomes are uncertain, paths are unclear, and evidence is incomplete. It is not merely about solving a single equation; it demands a bold and focused approach. It is about narrowing uncertainty without expecting to eliminate it, and about building systems that reflect both technical rigor and human understanding.

And, ultimately, it is about having the discipline to question the limits you are given, because sometimes the only way to build something that has never been done is to refuse to accept that it cannot be done.