The Scale-Up Question: Building Teams Project by Project

Every growing drone operation in Canada faces the same question: do you build a permanent team large enough to handle your biggest projects, or maintain a lean core and scale through a network of qualified contractors?

We've chosen the second path. Our core team is small. When larger programs require more capacity, we draw from a network of highly qualified operators we've built relationships with over time. When projects end, we scale back down. Fixed costs stay manageable. The cycle continues.

Neither approach is obviously right. Both have costs that aren't always visible until you're living with them. This is an honest look at the trade-offs we've experienced.

The Reality of Drone Work in Canada

Let's be honest about what the Canadian commercial drone market looks like for most operators. Work is seasonal in many sectors - agriculture, construction, and environmental monitoring. Projects cluster unpredictably - you might have several large programs in two months, then nothing substantial for six weeks. Geographic distribution matters—a project in northern BC doesn't help you if your team is based in Ontario.

This creates a fundamental mismatch between client demand patterns and the economics of full-time employment. A team sized for your peak capacity sits idle during slower periods. A team sized for your average workload can't handle the projects that actually pay well. And in a country this size, maintaining crews in every region where work might appear is financially impossible for most operators.

The result is that most of the Canadian drone industry operates with some version of a gig economy model, whether operators explicitly think of it that way or not. Full-time positions exist, but they're concentrated in a handful of larger companies or specialized niches. For the rest of the industry, scaling up and down with demand is the norm.

What We Gain From Project-Based Scaling

The financial math is straightforward. A skilled RPAS pilot with the certifications and experience to work on industrial projects might cost $80,000 to $120,000 annually in salary and benefits. If your project pipeline only requires that person's skills for six months of the year, you're paying full freight for half-capacity utilization. Multiply that across a team of four or five, and the carrying cost of idle capacity becomes substantial.

Project-based scaling lets you match costs to revenue more precisely. When work materializes, you bring on the people needed to execute it. When work ends, your costs decrease proportionally. The gap between income and expenses stays manageable because you're not carrying a workforce through periods without projects to support them.

There's also a capability argument. Different projects require different skill sets. A LiDAR mapping program needs different expertise than a thermal inspection project. Marine operations require different qualifications than work in controlled airspace. Maintaining all those specializations in-house means either hiring multiple specialists who each work part-time, or expecting a small team to maintain currency across an unrealistic range of competencies. A network model lets you bring in the right specialist for each project without carrying that overhead year-round.

Geographic flexibility matters too. We've done work across Western Canada, from coastal BC to the northern territories. Maintaining permanent staff in every region where work might appear is impractical. But we've built relationships with qualified operators in different areas who can join our programs when geography makes sense. A project in Alberta might involve our BC-based core team plus local operators who reduce travel costs and bring regional knowledge.

What We Pay For It

Here's where we need to be honest about the costs, because they're real and they're recurring.

Every time we scale up for a project, we go through a verification process. What certifications does each person hold, and when do they expire? What equipment are they proficient with? When did they last fly the specific platforms we're deploying? What site-specific training have they completed? What's their current medical status? The answers change constantly—certifications expire, people gain new qualifications, equipment proficiencies lapse if not practiced regularly.

We maintain records on our network, but those records are only as current as the last time we verified them. Someone we worked with six months ago might have let a certification lapse, or might have upgraded their qualifications, or might now be committed to another contract during our project window. The administrative burden of keeping this information current and re-verifying it before each project - is substantial. It doesn't generate revenue, but it's essential.

Training is another ongoing cost. We have specific ways of operating—our procedures, our documentation standards, our safety protocols, our communication practices. When someone joins a project, they need to understand how we work, not just how to fly. If they haven't worked with us recently, that means refresher training even if they're technically proficient. Every project involves some ramp-up time getting the extended team aligned on how this specific operation will run.

The inverse is also true: between projects, we lose the benefit of the learning that happened. A team that works together continuously develops shorthand, builds shared mental models, improves efficiency through repetition. A team that assembles project by project starts closer to baseline each time. You don't lose everything; working with the same people repeatedly builds institutional knowledge, but you don't accumulate it as quickly as a permanent team would.

The Hidden Costs of the Alternative

Before concluding that project-based scaling is a necessary evil, it's worth considering what the alternative actually costs.

Maintaining a full-time team through slow periods means either accepting losses during those periods or finding work to keep people busy, which often means taking projects at margins you wouldn't otherwise accept or assigning people to tasks that don't leverage their expensive skills. A $100,000-per-year pilot doing equipment maintenance or business development because there's no flying work isn't a good use of that investment.

There's also a risk concentration issue. A small permanent team means your operational capacity depends on a few individuals. If your primary pilot is sick, injured, or leaves the company, your ability to execute drops significantly. A network model spreads that risk; you're never dependent on any single person outside your core leadership being available.

Full-time employment creates expectations that can constrain business decisions. Turning down a project because it doesn't fit your strategic direction is easier when you don't have salaries to cover. Taking on work you shouldn't, because you need to keep people employed, leads to capability drift, quality issues, and reputation risk. The pressure to say yes to everything is higher when fixed costs are higher.

What Makes the Network Model Work

Not all project-based scaling is equal. The difference between a model that works and one that creates constant problems lies in how deliberately you build and maintain the network.

First, you need to actually know the people. Working with strangers found through job postings introduces too much uncertainty. Our network is built from people we've worked with directly, people recommended by others we trust, and people we've evaluated through smaller projects before relying on them for critical work. By the time someone is handling a significant role on a major program, we've already seen how they operate.

Second, you need systems for tracking qualifications and availability. We maintain records of certifications, training, equipment proficiencies, and contact information for everyone in our network. It's not perfect; information goes stale, people forget to update us, but it gives us a starting point when staffing a project. We know who might be qualified before we start making calls.

Third, the administrative burden of bringing people onto projects needs to be systematized. We have standard onboarding documentation, project-specific briefing templates, and defined processes for verifying current qualifications. This doesn't eliminate the ramp-up cost, but it makes it predictable and ensures nothing critical gets missed.

Fourth, relationships need maintenance even between projects. Checking in with network members periodically, sharing industry updates, and including them in training opportunities when possible - these investments keep the network active rather than dormant. When a project materializes, you're reaching out to people who already feel connected to your operation, not cold-calling former colleagues.

The Certification Currency Problem

One challenge specific to aviation-adjacent work deserves separate attention: maintaining certification currency across a distributed team.

Transport Canada requires pilots to maintain recency, recent flight experience on the specific category of aircraft they'll operate. Our own standards add requirements beyond the regulatory minimum: recent experience with specific platforms, current training on our procedures, and completion of any client-required certifications. For industrial work, there's often additional site-specific training that expires annually.

When someone flies regularly for your operation, maintaining currency is straightforward; it happens naturally through work. When someone joins projects intermittently, you need to verify currency at each engagement and potentially provide refresher training. This isn't bureaucratic overhead; it's aviation safety. But it's a real cost that doesn't exist in industries without similar certification requirements.

We've partially addressed this by offering periodic training opportunities to our network, even outside of specific projects. A training day where network members can maintain currency and practice procedures benefits everyone; they stay current, we verify their skills, and when a project comes up, less ramp-up is required. It's an investment in the network's capability that pays off across multiple future projects.

When Permanent Teams Make Sense

Despite our current model, we're not ideologically committed to project-based scaling. There are circumstances where building a larger permanent team becomes the right choice.

If your work becomes more predictable, a long-term contract, a retainer relationship, or a seasonal pattern you can staff around, the economics shift. Guaranteed revenue to cover fixed costs changes the calculation. At some point, the overhead of constantly scaling up and down exceeds the cost of maintaining capacity through slower periods.

Certain capabilities are hard to maintain through a network. Highly specialized skills, proprietary knowledge, or roles that require deep integration with your business processes may need to be held in-house. As operations become more complex, the core team often needs to grow even if project-based scaling continues for surge capacity.

There's also a ceiling on how large a network-based operation can effectively scale. Coordinating dozens of contractors across multiple simultaneous projects requires management infrastructure that eventually justifies full-time positions. The network model works well at certain scales; beyond that, you're building a different kind of organization.

The Relationship Reality

There's an aspect of this that business analysis tends to miss: the human relationships that make a network function.

The people in our network aren't interchangeable resources. They're skilled professionals with their own businesses, their own client relationships, their own preferences about what work they take. When we call to staff a project, we're asking them to prioritize our work over other opportunities. That only happens because we've built relationships where they trust we'll treat them fairly, pay promptly, and put them in positions to succeed.

This means the network is an asset that requires cultivation. Taking care of people during projects—clear communication, reasonable expectations, genuine appreciation for their contribution—builds the relationship capital that makes them want to work with you again. Burning people out, paying late, or creating chaotic working conditions depletes that capital. Eventually, the calls don't get returned.

We try to be the kind of operation people want to work with. That's partly self-interest; we need them more than any individual needs us, but it's also just the right way to operate. The drone industry in Canada is small enough that reputation travels. How you treat the people who help you scale determines whether they'll be there next time.

Where We've Landed

Our model isn't perfect. Every time we staff a larger project, there's friction, verifying qualifications, aligning procedures, and getting everyone up to speed on the specific operation. Every time a project ends, we lose some of the team cohesion that was developed. The administrative burden of maintaining the network and managing the scaling process is real.

But for where we are right now, a company in a market with variable demand, doing work that requires different capabilities for different projects, operating across a large geographic area, project-based scaling makes sense. The alternative would be either carrying costs we can't sustain or limiting ourselves to work that fits a fixed team's capacity.

The key insight, if there is one, is that this isn't a problem to be solved but a trade-off to be managed. You're not choosing between a good option and a bad option. You're choosing between different sets of costs and constraints. Understanding what you're actually trading, visibility, flexibility, capability, relationship investment, lets you make the choice deliberately rather than defaulting into it.

We've invested in building a network of people we trust, systems to manage the complexity, and relationships that make scaling work smoothly. Those investments have costs. But they've also given us the ability to take on work we couldn't handle with a permanent team our size, and to survive slow periods that would have broken a larger fixed-cost structure.

Other operators will make different choices based on different circumstances. That's fine. The Canadian drone market is diverse enough that multiple models can work. What matters is understanding the actual trade-offs, not the simplified version where one approach is obviously superior.

---

Aeria Solutions operates with a small core team supplemented by a network of qualified operators for larger programs. We're always interested in connecting with skilled pilots who share our approach to safety and professionalism. If you're building your own network or thinking through similar questions about scaling, we're happy to compare notes.