Earning the Right to Vertically Integrate

When founders talk about vertical integration, they usually talk about it as if it is self-evidently sophisticated. Own the full stack, own the margin, own the customer experience, own the data, own the moat. In the right conditions, all of that can be true. I understand the appeal because I built one of those companies. I also learned, the hard way, that vertical integration is not something you simply decide to do because it sounds strategically elegant. It is something the market, the capital environment, and your own operating maturity have to let you carry.

At Swoop Aero, we built a full-stack aerospace technology company. We designed, prototyped, and manufactured physical aircraft that could fly beyond the horizon. Around that, we built the software ecosystem needed to make the system commercially useful: fleet management, operations management, remote pilot tooling, off-board observer platforms, maintenance systems, scheduling, consignment tracking, sensors, a digital twin architecture, and the data systems that let us understand what had happened in the field and increasingly predict what might happen next. Then we commissioned every aircraft into service against that software ecosystem and ran a delivery operation on top of it. From the moment we started spending cash on a physical aircraft to the moment that asset was commissioned and earning recurring revenue, the cycle could be anywhere from four to nine months. It was a powerful model, and an extraordinarily capital-inefficient one.

That is a lot of company.

The mistake was not that we vertically integrated. The mistake was that we did it before we had really earned the right.

Vertical integration is not something you declare in a strategy deck. It is something the market allows you to carry.

The clean version of the story would be that we studied the market, admired a group of great full-stack companies, and concluded that building everything ourselves was the obvious strategic move from day one. That is not really what happened. Our original intention was much more pragmatic. We wanted to use commercial off-the-shelf components where it made sense, then concentrate our effort on the parts of the system that genuinely differentiated the customer experience. That is a sensible early-stage instinct. Build what matters. Buy what does not. Move quickly.

Once we started operating at real commercial scale, that plan fell apart.

The global supply chain for small drone components, especially the low-cost, high-quality, commercially reliable end of the market, simply was not mature enough for what we needed. The Australian supply chain certainly was not. We were building for regulated operations where reliability, traceability, and safety mattered far more than they do in consumer or hobbyist systems. We could not bolt together a loose stack of third-party parts, hope they behaved as promised, and then ask customers and regulators to trust the result. We integrated because the alternative was a product we could not fully stand behind. In that sense, vertical integration was not fashionable or ideological. It was the least bad option available to us at the time.

That distinction matters, because being forced into vertical integration is not the same thing as being ready for it.

There were genuine and important upsides to owning the stack. First, it gave us control over risk. In a safety-critical system, the aircraft is not just an airframe. It is an interconnected system in which hardware, software, maintenance, operations, data, and human workflow all affect each other. By owning more of that stack, we could control risk through the whole chain rather than simply managing whatever risk was handed to us by suppliers.

Second, it removed integration friction. This is one of the least discussed but most important realities of product development. Integration friction is the invisible tax you pay when two components were not designed together and you force them to coexist anyway. Sometimes it shows up as extra weight. Sometimes as awkward data interfaces. Sometimes as heat, vibration, mounting constraints, latency, or strange software workarounds that only appear in the field. If you are buying multiple commercial components and then designing your product around their inconsistencies, you are constantly paying for someone else's design assumptions. We saw that early. If we did not build key pieces ourselves, we ended up designing the aircraft around what those components happened to look like, rather than designing the whole system around what the customer needed.

Third, and most importantly, ownership of the stack let us move quickly when the learning loop was working. When a problem appeared in the field, we could trace it through the system, understand what had happened, and change the hardware, software, or operating procedure ourselves. We did not need to wait on third-party priorities or accept that a poor interface was simply "part of the platform". That mattered enormously because Swoop's real edge was not just the technology itself, but the speed at which we could learn from live operations and turn those lessons into product improvements. Vertical integration made that possible. In the best periods at Swoop, it was a genuine superpower.

Fourth, it gave us complete product control. If you genuinely understand the customer, owning the stack lets you translate that understanding through every layer of the system. You are not negotiating with suppliers to get to the experience you want. You simply build it. That becomes especially powerful when the business runs on trust and credibility, because a tighter product experience is not just aesthetically pleasing, it is strategically valuable. In regulated markets, trust is part of the product.

So I do not look back on vertical integration and think it was naive or foolish. It helped us move quickly, build a strong system, and solve real customer problems. But what I understand much more clearly now is that vertical integration removes integration friction while adding capital friction, supply-chain friction, and organisational friction. The bill arrives later.

Vertical integration removes integration friction. It adds capital friction.

The hardest thing about vertical integration is that many of its costs show up after the benefits have already convinced you that the strategy is right. Early on, everything feels coherent. The product improves quickly. The team feels clever. The customer experience tightens. The system starts to look like a moat. Then the weight appears. You are not just building a technology company. You are simultaneously building a design organisation, a software company, an advanced manufacturing business, a support organisation, and a field operations company. All of that sits on the same balance sheet. All of that needs leadership attention. All of that compounds.

Nothing is someone else's problem.

That sounds empowering when things are going well. It is much less romantic when they are not. If a component misbehaves, it is your issue. If a subsystem degrades in the field, it is your issue. If the product does not perform as expected, it is your issue. There is no supplier to escalate to, no external partner to lean on, and no one else to absorb the risk. If the company becomes leaner because the capital environment tightens, you still carry the whole stack. The technology does not get simpler just because the market gets harder. That was one of the hidden costs for us. We were proud, rightly, of doing a lot with relatively little capital. It forced discipline, customer closeness, and focus. But a lean capital strategy in a fully integrated business also means you often do not have much room to manoeuvre when the environment turns against you.

This is where the idea of core competency becomes much more useful than the simplistic question of whether vertical integration is good or bad.

If I look back honestly at Swoop, our real core competency was not manufacturing in and of itself. It was field operations, learning from those operations, and then turning that learning into better systems, better product decisions, and better operating performance. We were very good at taking operational reality, translating it into innovative technical solutions, and getting those solutions to the point where they were ready for repeatable deployment. That is different from saying that circuit board manufacturing was a core competency, or composite manufacture, or wiring-harness production. Those things mattered deeply, but they were not the deepest source of our advantage.

That is the distinction I would make much earlier now.

As the global capital market tightened in 2023 and we were forced to become more ruthless about what the company should and should not carry, we began doing the right things, just a little too late. We started to identify which parts of manufacturing were not actually core to Swoop's enduring advantage and which parts should remain close to the company. Composite supply chain, circuit board manufacture, wiring and harness manufacture, these were all areas where we increasingly wanted third-party suppliers to take responsibility once we had worked out the operationally correct solution. Our intention was to drive those subsystems through development far enough that we knew exactly what "right" looked like, then outsource repeat manufacturing while retaining final assembly, commissioning, and quality assurance in-house. That would have let us keep control over the customer-critical end of the process while pushing lower-value manufacturing risk back into the supply chain where it belonged.

Alongside that, we needed to renegotiate strategic supply agreements so that when supplied components were not to specification, or failed to meet our quality standards, that risk did not simply sit with us by default. During the earlier development phase, when the technology was still moving quickly and the supply chain options were thin, we had not built enough of that discipline into the supplier relationships. Later on, we knew better. We wanted suppliers held to account, with clearer performance obligations and a more deliberate transfer of manufacturing risk back out of the company. That was the right direction. We simply started it later than I now believe we should have.

That is one of the clearest lessons I carry forward. If you do decide to vertically integrate early because the category leaves you little choice, you still need a plan for when and how parts of that stack will stop being core. Vertical integration can help you discover the right solution. It does not automatically mean you should manufacture every subsystem forever.

Your core competency is not the same thing as everything you currently do.

The location question sits right underneath this, and I think founders underestimate it all the time. We built Swoop in Australia, and there were many good reasons to do that in the earliest phase. It was where the founding team was, where we could prototype quickly, where we could build the initial business, and where we could take advantage of the network and operating environment available to us. For research and development, prototype manufacture, and the first phase of platform development, that can absolutely work. But the lesson I hold much more tightly now is that the place where a company begins is not necessarily the place where it should scale manufacturing.

When I look back at the supply chain reality we were dealing with, the asymmetry is obvious. In Australia, for many major aerospace-grade components, we effectively had a single-source supplier. In a deeper manufacturing environment such as the United States, parts of Europe, or even parts of South East Asia, you might have ten or a hundred credible suppliers for the same category. That changes everything. It changes pricing power, redundancy, lead times, supplier accountability, technical support, and the company's ability to transfer risk. It also changes the founder's strategic flexibility, because a thin supply chain quietly locks you into decisions that look like technical choices but are actually environmental constraints.

This is why the phrase "earning the right to vertically integrate" has become so useful for me. It is really a question about whether the company, the environment, and the market can all carry the weight of the complexity you are taking on. You earn that right when you have enough customer clarity to know which parts of the stack genuinely matter. You earn it when the learning loop is strong enough that ownership turns into real speed and product improvement. You earn it when the capital environment can sustain the working capital cycle you are choosing to carry. You earn it when your supply chain geography is a reasonable match for the burden of manufacture. And you earn it when you know what is core, what is adjacent, and what should be handed off as soon as the solution is sufficiently well understood.

At Swoop, we integrated because we had to. What I understand now is that necessity is not the same thing as readiness.

If I were building a similar company again, I would still take vertical integration seriously. In some categories, particularly safety-critical ones, it remains the right strategic answer for at least part of the journey. But I would earn the right much more deliberately. I would stay modular longer. I would be more disciplined about which layers genuinely differentiate the customer outcome and which layers are simply convenient to own because founder psychology tends to prefer control over compromise. I would bring the most important parts in-house first, use the field to discover what "right" looks like, and then outsource repeat manufacturing of non-core components far earlier once the design had stabilised. I would retain final assembly, system integration, commissioning, and quality assurance closer to the company, because that is where trust, performance, and customer experience still converge. And I would think much earlier about where the company should physically live as it transitions from development to scaled manufacture, because geography is not background in a physical-world business. It is part of the architecture.

This is the lesson I now care about most. Vertical integration is not about wanting to own everything. It is about knowing what the company must own to learn quickly, build trust, and deliver a better system than the market can otherwise produce. Everything beyond that needs to justify its weight.

Owning the whole stack only helps if the company can carry the whole stack.

I still believe vertical integration can be one of the most powerful strategies in deep tech. It can tighten the learning loop, reduce integration friction, improve quality, and create extraordinary customer experiences. It can also quietly become the thing that makes the company too heavy for its environment. The lesson I carry forward is not that vertical integration was wrong. It is that timing, capital, supply chain depth, geography, and a precise understanding of core competency matter just as much as technical conviction.

You do not earn the right to vertically integrate by wanting it badly enough.

You earn it when the company, the market, and the environment can all carry the weight.