RunPilot

I came into this through engineering and research. During my PhD, I was working on computational methods for generating and assessing infrastructure options, and I was always interested in how that research could be applied to real infrastructure problems. I knew quite early that I wanted to move towards industry and eventually build something commercially.

As we started applying the research to real problems and speaking to engineering, GIS and permitting teams, the bigger problem became obvious. Generating a technically good route was only one part of the decision. Early infrastructure planning brings together engineering, land, environment, permitting, cost, stakeholders, and communities, but those considerations are often handled in different tools and by different teams.

A lot of the evidence needed to make those decisions was fragmented across GIS tools, spreadsheets, reports, legal documents, and workflows. My co-founder Joe and I saw an opportunity to bring that together in a more useful way.

RunPilot grew out of combining the models we had developed through our research with what infrastructure teams were telling us they actually needed. Rather than treating network design, route development and deliverability as separate exercises, we started bringing them into one optioneering workflow and testing that approach on real infrastructure problems with industry partners. That was really the point where the research started becoming a product.

Early-stage infrastructure development is highly fragmented. Engineering, routing, land, environmental assessment, permitting, cost and stakeholder considerations are tightly connected, but the work is often carried out sequentially or across separate tools and teams.

RunPilot brings those considerations into one system. Teams can develop and compare infrastructure options at different levels, from wider network and site decisions through to corridors and detailed routes, and test them against engineering, environmental, land, permitting and cost evidence.

We are also bringing in evidence that is often much harder to use systematically at this stage, such as previous planning decisions, permitting history and community response, so teams can understand the development context around an option rather than looking only at physical constraints.

The important point is that the route, the wider system and whether something can actually be delivered are not separate questions. The best local route does not necessarily produce the best overall network, and a technically attractive option may still create major land, environmental or permitting problems.

We want that decision process to be testable, repeatable and transparent. If an assumption, constraint or design changes, teams can reassess the options rather than rebuilding the analysis manually.

Ultimately, the aim is to let infrastructure teams explore more credible options earlier, understand the trade-offs between them and retain the evidence behind the decisions they make.

The technical capability of the software and the customer value are not the same thing. It's easy as an engineering or technical company to focus on everything the software can do and calculate, but what matters to the customer is whether it helps them make a better decision, faster and with less effort. We learned quite quickly that a technically sophisticated feature is not automatically a valuable product feature. The question has to be, does this remove work, de-risk a decision, or allow the customer to do something they could not reasonably do before?

On the problem we're solving specifically, it is the assumption that infrastructure planning can be treated as a sequence of separate optimisation exercises. In reality, the decisions interact. A change to the network configuration can alter the best route. A land or environmental constraint can change the engineering solution. New permitting evidence can make an option that looked attractive much less deliverable. A more useful approach is not to optimize each step in isolation, but to test the development decision as a connected system.

Go out and test your problem, wherever you can find people who have relevant knowledge or are in the industry and actually know. Talk to customers earlier than feels comfortable. You can spend a lot of time perfecting something technically when a conversation with somebody who's actually doing the job can tell you very quickly that this won't work, or that this other thing matters more. Invest heavily in the underlying technology, but connect product development and customer feedback. The two have to develop together.

For RunPilot, success would be becoming a normal part of how major infrastructure organizations make early-stage planning decisions, across electricity networks, pipelines, water and other large infrastructure systems. I would like to get to a point where teams can test dozens of credible options early, understand the engineering and deliverability trade-offs between them, and update those decisions as circumstances change, rather than repeatedly rebuilding the analysis across disconnected teams and tools.

Personally, success looks like skill development. I've got a lot to learn, and I want to learn more.