The lessons I paid to learn founding Swoop Aero

In December 2018, after the first commercially contracted vaccine delivery by drone in Vanuatu, we celebrated quietly with local lobster mixed through baked beans because that was what was available, the internet was down, the phones barely worked, and we had to be ready to fly again the next morning. At the time, I thought the hard part was building the technology. I thought that if we could design a system that could move critical cargo over ridgelines, land in tight spaces, operate safely enough for regulators to trust it, and do it under a real commercial contract, the rest would follow.

I was wrong.

The technology was hard. The company was harder.

I am writing this because, as I got back into building, I realised I had a responsibility to do something more useful than simply move on. I needed to understand, very clearly, what had worked at Swoop, what had not, and which lessons were actually worth carrying into the next company, the next executive role, and the next chapter of my career. I did not want the emotionally convenient version. I did not want the founder mythology, and I did not want the flattened post-mortem that makes every outcome look obvious in hindsight. Small minds talk about people; great minds talk about ideas. The people mattered deeply while we were in it, but the ideas are the durable part now. They are the part that can still teach.

Growth = pain x reflection. Publishing this is part of that growth for me.

Swoop proved something very real. Autonomous logistics can create meaningful value in the world. It is not just a render, a lab experiment, or a story told in a venture deck. We built a real system, under commercial contracts, in regulated environments, delivering critical healthcare and other supplies in places where the existing logistics infrastructure was expensive, slow, or simply not good enough. We proved drone logistics at scale was a real commercial category worth pursuing and turned down a $100m takeover offer. The company also entered administration. Both halves of that story matter, and the distance between them is where most of the learning lives.

The technology was hard. The company was harder.

One thing I want to correct clearly at the start is this: Swoop did not go wrong because we were poor at sequencing R&D with sales and operations. For a long stretch, that was one of the strongest things we did.

From the beginning, I believed our edge had to be speed of learning. I did not come into autonomy thinking we would win by spending years building a perfect system in a lab, nor did I think we would win by throwing immature hardware into the field and calling the resulting mess "iteration." Our advantage had to come from learning faster than the environment changed around us and then turning that learning into product, process, and operating advantage.

That instinct came directly from aviation. In the Air Force, the OODA loop (observe, orient, decide, act) was not an abstract framework. It was the work. You absorbed information, built a picture quickly, made a decision under pressure, acted, and then did it again before the environment had moved too far ahead of you. I carried that into Swoop almost intact. The company had to be designed to learn.

That meant starting with real customer requirements rather than a cool technology looking for relevance. Our earliest product requirements were built around two real, hard problems: vaccine delivery and pathology logistics. Those customers gave us clarity that I think was unusually valuable at that stage. Payload mattered. Range mattered. Chain of custody mattered. Real-time tracking mattered. Cold-chain compatibility mattered. Reliability mattered. We were not inventing a toy and hoping someone would find a use for it later. We were solving a logistics problem with human consequences.

It also meant accepting that the first version of the company would be people-and-process heavy, and technology-light. That was not a flaw. It was the bridge. Early autonomy is often disciplined operators, strong checklists, good mechanics, clear workcycles, and a thin layer of technology gradually earning the right to do more. That was our path. We used people and processes to create reliability, then systematically built the technology stack so that more and more of the burden moved from human effort into product capability.

That sequencing was one of the reasons we got as far as we did.

To make it work, we had to build more than an aircraft and a software stack. We had to build organisational infrastructure designed for learning. I blended Air Force workcycles with the "company heartbeat" ideas I had seen in consulting, and over time that became a single operating rhythm across an increasingly global business. Slack was open and structured, with minimal side channels. Situation reports came in from the field. Meetings had a clear purpose, a decision maker, and an outcome. Daily standups, weekly ops syncs, monthly safety reviews, and quarterly strategy sessions created scaffolding that was strong enough to hold the company together, but not so rigid that it slowed us down. Engineering, operations, manufacturing, commercial, and leadership stayed in the same learning loop.

That mattered. It mattered a lot.

Because when the company was running well, a flight did not just deliver cargo; it generated data, and learning. That learning came back into the product, the systems, the operating procedures, and the conversations quickly enough that the next flight was better than the last. In the best periods at Swoop, we did this exceptionally well.

Speed of learning is not a slogan. It is a designed system.

Another thing we got right early was understanding that trust came before scale.

When I stepped into startups, one of the most uncomfortable truths was that I did not really know how to sell. Consulting firms walk into rooms with decades of institutional credibility behind them. Startups do not. You begin with no installed base, no category legitimacy, no inherited trust. So the question becomes: how do you build enough trust that people will take a risk on something that does not yet fully exist?

That question shaped Swoop more than I realised at the time.

Vanuatu was where the lesson became concrete. When the tender for medical drone delivery was released, a number of companies expressed interest. I was the only person who showed up in person. That was not some polished commercial tactic. It simply felt obvious. I had worked in Vanuatu before and understood that effort mattered. More importantly, I wanted to understand what the people on the ground were actually dealing with. I met ministry staff, nurses, regional coordinators, and field teams. I listened. I asked questions. I took notes. What became clear very quickly was that these were not abstract logistics problems. They were human problems. The people on the ground did not need disruption for its own sake; they needed tools that worked in their context, with local operation, in real conditions, without forcing them to redesign their lives just to use a new technology.

That insight shaped the company. It shaped the product, the deployment model, and the way we sold. It also led to what I now describe as the Impact Flywheel: do meaningful work, capture it honestly, tell the story well, and use the resulting trust to earn the next opportunity. That flywheel worked because the work was real. The story did not carry the execution; the execution carried the story. Media attention, credibility, inbound demand, and partnership conversations all flowed from the fact that we were doing something that actually mattered.

The harder lesson came later. Once trust becomes part of the product, every drop in performance lands much harder than the spreadsheet says it should. A delay is not just a delay. A weak handoff is not just an operational issue. In a regulated, safety-critical business, performance problems become fractures in confidence, and confidence is extremely expensive to rebuild.

Trust is part of the product.

If there is one non-technical thing I am genuinely proud of at Swoop, it is that we built culture deliberately.

We did not treat culture as mood music or employer branding. We treated it as infrastructure. We were trying to invent a category, across geographies, functions, and enormous technical complexity. The team needed more than tasks and KPIs. They needed clarity, identity, belief, and a shared language for doing something improbable together.

So we built it.

We built rituals. We built a shared language. We built onboarding that brought people into a distinct operating culture. We built a big mission that people could actually connect their work to. During COVID, all of that became even more powerful. Melbourne lockdowns turned the company into something closer to a deployment. The office became a frontline base. Shared hardship created extraordinary cohesion. The rituals mattered more, not less. We created a wartime culture, and during wartime it was incredibly effective. It created speed, resilience, camaraderie, and a willingness to endure difficulty together that I have rarely seen elsewhere.

Where I got it wrong was not in building culture so intentionally. It was in not adapting it early enough when the external environment changed.

This is an important distinction. During COVID, Swoop's tempo made sense because the external world was constrained too. Life had narrowed. The company's intensity felt proportional to the intensity outside it. Then COVID ended. Borders reopened. Weddings, birthdays, weekends, ordinary social life: all of that came back. The wider world moved back toward something like peacetime. Swoop, however, largely stayed on wartime footing. The same rituals and tempo that had created energy during the crisis began to create strain in normality. What had once felt noble and galvanising became, over time, harder to carry. The problem was not that the culture had been fake. The problem was that it had been designed for one environment and we did not evolve it quickly enough when that environment changed.

With hindsight, this mattered much more than I appreciated at the time. Weddings were missed. Birthdays were missed. The sacrifices that once felt energising became heavier. We mistook endurance for strength. In reality, the company needed a peacetime operating mode which we weren't funded for, and our lean posture left us very little room to redesign the engine while we were still flying. That is one of the deepest leadership lessons I carry out of Swoop. Culture is not static infrastructure. It is living infrastructure. If you build it deliberately, you also have to evolve it deliberately.

Culture is living infrastructure.

We understood relatively early that the need was real. Pathology logistics, vaccine delivery, and critical medical supply chains all had genuine pain inside them. In some networks, relatively small changes could create very large improvements in cost, service, and accessibility. The problem was not whether the need existed. The problem was how the value was unlocked.

What we underestimated, especially in more mature healthcare and logistics networks, was the complexity of the adoption architecture when the customer only captures the full value after redesigning part of their operating model.

That creates a very particular commercial challenge. You are not just selling a product. You are often asking a customer to adopt a new operating logic. That means pilot, trial, implementation, trust-building, procurement, internal championing, and usually a long period in which the startup is investing heavily (i.e. burning cash runway) before the customer is ready to rapidly adopt full scale. In categories with lower perceived downside risk, that can still be manageable. In medical logistics, where failure can carry real operational, legal, and reputational consequences, the customer's risk tolerance is much lower.

That is one of the biggest category lessons I carry now: the best autonomy businesses create incremental value before they require system-wide change. If the product asks the customer to redesign their whole operation on day one, adoption gets hard very quickly.

That idea sits beside another one that became and remains central for me.

Autonomy only matters if it completes the mission.

Getting close is not delivery. Flying beautifully is not value. A clever autonomous system is not a business. The job has to get done, reliably, safely, and in a way that lowers friction for the customer rather than increasing it. That insight sounds simple written down, but it is not simple when you are deep inside frontier technology. Swoop taught it to me the hard way.

I still believe vertical integration was strategically right for Swoop. Owning more of the stack helped us move faster, control quality, tighten the feedback loop, and build a stronger product with comparatively modest capital for the category. That was real. It mattered.

But vertical integration has a shadow side. It is heavy. It pulls manufacturing complexity, supply chain risk, support burden, quality systems, working capital needs, and operating risk onto the same balance sheet. It can be a strong moat in the right environment. It can also become fragility in the wrong one.

One of the harder truths I carry now is that we did not simply "fail to scale manufacturing" in some simplistic sense. The deeper issue was that we were scaling manufacturing, introducing a new product generation, supporting legacy systems, operating globally, and evolving the commercial model all at the same time. Those are several hard companies bundled together into one. Australia added another layer of difficulty: a thinner supply chain than ideal for aerospace manufacturing, operating markets often sitting in different time zones, and a capital environment that was not as deep as the company's complexity probably deserved.

COVID also made structural changes much harder during exactly the earlier years when they may have mattered most. With travel and movement locked down and a global supply chain faltering, our only real option was to double down on vertical integration.

During COVID, we also adopted a second business model. Alongside designing, manufacturing, and operating networks ourselves, we launched a leasing model (later framed more clearly as Hardware-as-a-Service) so that partners could operate aircraft in places we could not easily travel to. At that stage it was a minority line of revenue and a sensible adaptation to the environment. It let us maintain a foothold in markets that might otherwise have gone dark.

The subtler lesson came later, when that adaptation began to change the company's centre of gravity.

To keep growth moving, and to reduce the apparent risk of relying too heavily on a small number of large and often lumpy Government and Health programmes, we went broader across customers and geographies rather than going much deeper into a single beachhead. On paper, that de-risked concentration. In reality, it loaded operational complexity into the system. Smaller fleets in more places, more customers across more time zones, more support threads, more similar-but-not-identical problems, and more strain on engineering, field support, and culture all at once.

This is one of those lessons that looks obvious only after it has already cost you. A secondary business model can be a brilliant adaptation in one environment, and then quietly reshape the whole company if you are not extremely deliberate about how it scales.

Vertical integration is a weapon. In the wrong capital environment, it becomes a trap.

The sharpest lesson of all; and the one I will carry into every future executive role, is that under enough pressure we broke the very loop that had made us good.

We had built the company around speed of learning. That was not branding. It was the core competence. Then, under pressure to improve capital efficiency and keep growth moving, too many early aircraft from the new generation went directly into leasing customers' hands rather than being operated by us first in our own live environments.

On a spreadsheet, the logic was understandable. Margins looked cleaner. Revenue looked faster. The capital profile looked better. What the spreadsheet could not really see was the value of the learning infrastructure.

We had always learned by operating our own technology with paying customers in the field, inside our own workcycles, inside our own rhythm. That was how we stayed ahead. That was how the product improved. That was how we knew, quickly, what had happened and what to do next. Once we broke that, problems became second-hand. They were slower to diagnose, harder to reproduce, and easier to misunderstand. The clean signal that had made us fast started to disappear. Engineering slowed. Support slowed. Decision-making slowed. And because the team was already tired, the cost of that slowdown was even higher.

This is the deepest scar tissue I carry out of Swoop.

If the learning loop is your advantage, protect it with your life.

Given my time again, I would invest deeply into making the inherent value of the learning loop infrastructure explicitly clear. Not optics. Not short-term margin. Not cosmetic buzz words. Nothing should be allowed to break the system that makes the company smarter.

Swoop's capital strategy is one of the areas where I think the reflection matters most, because it changed how I think about building and leading companies.

For a long time, our lean capital strategy was a strength. It forced discipline. It forced focus. It forced customer closeness. It forced us to build only what mattered. We achieved a great deal with comparatively little capital for the complexity of what we were building, and I remain proud of that. But lean is only a virtue until it removes your room to manoeuvre.

By 2023, the company had reached the most capital-hungry phase of its life. Manufacturing ramp was hard, the new product introduction was hard, the team was tired, and the business model was heavy. Then the capital markets changed sharply. At exactly the moment when the business needed flexibility, we had very little slack in the system. That is the part I describe differently now. We were not simply caught by a bad market. We had built a company that fit one capital environment, and then found ourselves trying to turn it inside another.

As that environment tightened, we pursued a strategic M&A pathway because it represented the cleanest way to preserve the team, technology, shareholder value, and give the business a better platform than trying to force a capital-intensive business through a cold market on its own. When that path did not complete, we reluctantly accepted a bridge round. The bridge capital was directionally right and it bought time, but it was lighter than the business truly needed to make the full turn through to profitability. Additionally, it was a silent round; meaning we couldn't make an announcement to restart the trust flywheel with customers, and the 'debt disguised as venture' nature of a convertible note made closing additional funding all but impossible. There is a profound difference between having enough capital to continue operating and having enough capital to change the shape of the company. We had the former. We did not really have the latter.

The operating work in that period was real. We redesigned the commercial model, leaned much harder into Hardware-as-a-Service, outsourced complexity, improved margin, reduced bill of materials, renegotiated customer and supplier contracts, and shortened payback meaningfully. Those were the right moves. What I understand now is that when you start the turn late, and with too little room, even the right moves can still be insufficient. Essentially the same as combat in an Air Force Jet.

That experience changed how I think. The capital market is not background terrain. It is part of the environment the company is actually operating in. Like an aeroplane flying in the weather, you build a business early to be ready for changes in the forecast.

The type of company you build has to fit the capital market you are building it in.

The simplistic version of the lesson is "raise more." I do not think that is the most useful version. The better lesson is that a strategy needs to be aligned with the right capital environment early on, and that same company needs to build strategic degrees of freedom into its operating model early enough that it can adapt when (*not if*) the environment hardens around it.

I do not look back on Swoop as either a myth or a mess. It was a real company that solved a real problem, built real technology, and taught me a set of operating lessons that were expensive to learn and extremely valuable to carry.

I now believe, more strongly than ever, that speed of learning is one of the most defensible advantages a company can build, but only if it is treated as a designed system and protected as a core asset.

I believe that trust is part of the product, especially in regulated industries, and that the cost of breaking trust is much greater than most early teams realise.

I believe that culture can be a real competitive advantage, but only if it is allowed to evolve with the external environment rather than being romanticised or frozen in place.

I believe that technology only matters if it completes the mission, and that adoption gets hard when your technology asks the customer to redesign their world before they have experienced enough value to want to.

I believe that vertical integration must be earned, timed, and matched to the surrounding environment, because it can be a weapon and a source of fragility at the same time.

I believe that commercial model design and capital strategy are not separate from product strategy. In a physical-world company, they are product strategy.

And I believe that when a company finds the thing that makes it genuinely good, whether that is a learning loop, a cultural engine, or a particular market rhythm: the job of leadership is to recognise it early and protect it fiercely.

That is the value of Swoop to me now. Not the headlines. Not the mythology. Not even the ending. The value is that I know, in a much deeper way than I did before, which levers actually matter when you are building a venture-backed company in the real world. I know what it feels like when a culture is carrying the company, and when it has become too rigid for the world around it. I know how easy it is for a clever business model adaptation to quietly reshape the whole company. I know what happens when a spreadsheet improvement masquerades as a strategic improvement. And I know how to tell the difference between proving a category and building a company.

That is why I am comfortable being open about Swoop now.

Not because I think pain is inherently noble, and not because I want sympathy, but because I think the right reflection makes you more useful. More useful to founders. More useful to investors. More useful to teams. And certainly more useful as an executive.

The technology was hard. The company was harder.

That is what Swoop taught me.

And that is what I will carry into whatever I build, lead, or help scale next.