Autonomous Drone Delivery at Scale

Autonomous drone delivery has long been the stuff of science fiction, but ongoing advances have moved the space from experimental to operational. Zipline is one of the leading companies in this space, with drones that charge between missions and fly autonomously to deliver packages directly to customers. Kyle Madonia https://www.linkedin.com/in/kylemadonia/ is the VP of Application Software and IT at Zipline https://www.zipline.com/, and she previously spent a decade as an engineer at SpaceX. In this episode, Kyle joins Gregor Vand to discuss how Zipline’s software stack powers end-to-end autonomous delivery, the engineering challenges of managing drone fleets at scale, and how the team approaches software releases for safety-critical systems. https://i0.wp.com/softwareengineeringdaily.com/wp-content/uploads/2023/11/Gregor-Vand.jpegGregor Vand is a security-focused technologist, having previously been a CTO across cybersecurity, cyber insurance and general software engineering companies. He is based in Singapore and can be found via his profile at vand.hk or on LinkedIn. Please click here to see the transcript of this episode. http://softwareengineeringdaily.com/wp-content/uploads/2026/05/SED1933-Zipline.txt Sponsorship inquiries: [email protected] http://softwareengineeringdaily.com/wp-content/uploads/2026/05/SED1925-Reactive-Native-at-Coinbase.txt The post Autonomous Drone Delivery at Scale https://softwareengineeringdaily.com/podcasts/autonomous-drone-delivery-at-scale/ appeared first on Software Engineering Daily https://softwareengineeringdaily.com.

• 0:00Speaker 00

  Autonomous drone delivery has long been the stuff of science fiction, but ongoing advances have moved this space from experimental to operational. Zipline is one of the leading companies in this space with drones that change between missions and fly autonomously to deliver packages directly to customers. Kyle Madonia is the VP of Application Software and IT at Zipline, and she previously spent a decade as an engineer at SpaceX. In this episode, Kyle joins Gregor Van to discuss how Zipline's software stack powers end-to-end autonomous delivery, the engineering challenges of managing drone fleets at scale, and how the team approaches software releases for safety-critical systems.

• 0:45Speaker 00

  Gregor Van is a security-focused technologist, having previously been a CTO across cybersecurity, cyber insurance, and general software engineering companies. He is based in Singapore and can be found via his profile at van.hk or on LinkedIn.

• 1:14Speaker 01

  Hello and welcome to Software Engineering Daily. My guest today is Kyle Madonia.

• 1:19Speaker 02

  Hi, it's great to be here. Thanks for having me.

• 1:22Speaker 01

  Yeah, awesome to have you here today, Kyle. We're going to be talking about all things autonomous flying, which I don't think we've ever had an episode yet on this on Software Engineering Daily. So you are at the company Zipline, which we're going to get into in a second, as we like to do on Software Engineering Daily. I believe currently you're the VP of Application Software and IT at Zipline. You do have quite an interesting career path to getting to Zipline as well. I think that would be interesting just to hear about and sort of how it influenced, I guess, you then joining Zipline.

• 1:56Speaker 02

  Yeah, my background is all computer science. So I studied computer science in undergrad, grad school, started working as a software engineer in a few different companies and ended up joining SpaceX in 2013. It was a company that nobody had really heard of at that point. I hadn't really heard of it. And I thought, oh, it's aerospace, it must be boring and slow. Why would I want to go there? And then I visited the factory and I was clearly wrong and thought, well, this was a mission that I could really get behind. And I spent the next 10 years at SpaceX, growing into leadership roles, but really focused around building out the internal systems that we use there. So I built out Warp Drive, which is the Enterprise Resource Planning ERP system that SpaceX use, that

• 2:39Speaker 02

  Tesla also ended up using. I built out a lot of the systems there. I built out the Network Operating Center for Starlink, how we communicated with satellites, managed the fleet, the telemetry, a system that we had for that as well. Even worked on all kinds of random internal systems. For example, in Starbase, we built out a leasing system for how we handled leasing properties to employees who were now moving to Starbase. So it was just anything that SpaceX needed, we were building. And after about 10 years there, I started thinking, I wonder if now it's time to see what else is out there. And SpaceX had grown so much and was so successful in so many ways, that I wanted to see what else existed. That was really exciting. And it happened to be around this

• 3:21Speaker 02

  time that ZipLine contacted me and I started looking at what ZipLine was doing and seeing the mission that ZipLine had, where for the past around eight-ish years, ZipLine was serving medical products in Africa and delivering blood supplies, vaccines, nutritional supplies, all of these to really help save lives there and to help improve the health system in Africa. I felt like that was already such an important mission. But now ZipLine was at this inflection point of launching in the US. And we now want to bring some of this to the urban areas. And really, our goal is to be able to have a logistics system that serves all people equally. And I knew leaving SpaceX, like it had to be a mission that I really believed in, because that's important.

• 4:05Speaker 02

  To me, but I also wanted to be at this place where we weren't sure would it be successful? Because I think that's always such an interesting place to be where it's not when are we going to be successful? But it's if we're going to be, it's the same kind of thing in 2013 when I joined SpaceX. You didn't really know if we were going to be able to achieve this. And I saw that the areas that that zip line really was growing in was something that I could help in. So I decided to make the jump and join the company. And that was about two years ago and it's been a fun ride here now as well.

• 4:34Speaker 01

  Yeah, that's amazing. And I think it's very interesting how one huge mission effectively was taking humans off the planet. And like, how can we put them in a different place? And then this mission is all about humans on the planet, quite frankly, and I really like that. Yeah.

• 4:49Speaker 02

  Yeah, that's actually what I was saying when I started just putting out some feelers was that I wasn't actually sure what mission was after. Because how do you say changing your mission from making humankind multi planetary? Like, what is the next mission? I just want to do something here on earth. I've spent 10 years, how do we go and explore and be able to get off earth? But now I want to say, how do we make things better for people on earth? And zip line just had the perfect combination where we were trying to make things better for people on earth, but using the skies. And I thought that was so key to being able to make such a huge impact.

• 5:21Speaker 01

  Definitely. So we're going to get into the end to end experience of what is it blind is shortly. But just in more of like a super high level, you have touched on it. It's obviously you've mentioned deliveries, for example, but what is zip line? Just to get us understanding that one.

• 5:37Speaker 02

  So zip line is a company that does deliveries with autonomous drones. So we build and manufacture all of our drones here in the U.S. And then we deliver a variety of products. And the important thing for us is that we were able to deliver extremely fast and safely to people for whatever reasons you need it for. So part of our mission is always in the healthcare space. That's really our roots in launching in Africa and internationally with what we've done with our longer range drone that we have. And now with what we call our platform two, but it's more of our high precision drone that we have now launched in the U.S. We're delivering retail products. Food from restaurants, prescriptions. We still want to stay very close to the healthcare

• 6:19Speaker 02

  space. We're going to have more healthcare partners coming online. And really, again, it's about just delivering to people whatever they need. You know, when we talk about why I joined, I think when I was talking to ZipLine, I have two young kids and my kids, there was one night where my husband was out of town and both my kids were sick. Like, I just need Tylenol. Like, it had to be specifically Tylenol if you're a parent, like, you know. And I didn't know how to get it to the house because I needed it fast. And everything I was looking at was going to take so long. When you have two screaming children, like, you know, you cannot take a long time. It just happened to be the next week when ZipLine contacted me. And I thought, like, that would have been my solution. And I think that's what we're seeing as we launch. It's like, there are parents who are ordering formula for their babies, for medications for their kids,

• 7:04Speaker 02

  the elderly who have a harder time leaving. So that's why ZipLine is trying to solve these problems of delivering quickly for whoever needs it.

• 7:12Speaker 01

  Yeah. And I imagine you've talked how the core market at the moment, I believe, is in Rwanda and Ghana, for example. And what you've just mentioned, that's like amplified so much in these countries, these regions. There is no, let's just take a name, Uber Delivery for X. There's none of that, right? And so this is the only version that's not like a car having to traipse across a ton of landscape and that kind of thing.

• 7:35Speaker 02

  Yeah, in that model, we have centralized fulfillment. So we do all of the storage of the blood, of other medical supplies. So even in those countries, they don't need to think about how do you store that? And how do you make sure that you have quality products there? But the difference between flying and someplace like that is you can get somebody lifesaving supplies in minutes where a car would take hours, just in terms of how you would have to drive there.

• 7:57Speaker 01

  Yeah, exactly. So I think let's start to look at actually what happens. Set the scene more for when a user is actually using the applications that mean a delivery comes in. Just to be clear, what we're going to be touching on today, and given that we're a software engineer in daily, we're not going to be touching quite so much on, say, like, the hardware piece or the exact avionics, this kind of thing. We are going to be talking all about what is the software used by, especially The end user and for ZipLine internally to make this possible at all because there's just so many bits to this that to me is super interesting because the failure modes here are so different, I think, compared to many other software companies, especially the outcomes of what could

• 8:41Speaker 01

  happen if something fails is quite different to just like a server going down. We're talking like a whole plane autonomous plinking can go down. So let's look at the end to end experience. Walk us through where does this even start? Who is the customer, the user? Where does it start? And how does it all work?

• 8:57Speaker 02

  Yeah, I think if we're focusing on really where we're going and with this platform too, that we built out in the more high precision drone, but the way how this works now, we built out a marketplace. And so from a customer's point of view, it's super simple. You download the ZipLine app, open it, you put in your address, you get to see what partners can deliver to you. So that could be Walmart, if you live near one of those, it could be different restaurants that we're serving. Just go in, you figure out what you want to order, you place your order, and that is it. So we want the customer experience to be extremely simple and familiar. People know how to do that. From there, we get the order into our system. And so we have a set of delivery services that is then ingesting those orders through we use Kafka as our QA mechanism, right?

• 9:41Speaker 02

  So all these orders come in, we look at it and figure how we translate these orders into missions. Because on our side, what's unique for something like ZipLine is we have the fleet of drones. And so from that fleet, we need to figure out what is the ETA that we give back to the customer so they can see, oh, I'm going to get my medicine in 20 minutes. And just calculating that ETA is its own complexity. But as we look at what other missions do we have and orders coming in, what are the drones' battery levels? How far is this going to make sure we know how far to fly? All of those services are important to this whole experience, but it's all invisible to the customer. They don't see any of that. From there, if it is a restaurant, as an example, that we integrate with, we'll send the order directly to their point of sale system. So it's

• 10:23Speaker 02

  very familiar to the restaurant. Also, one of our goals, the operation side, is to keep it as simple as we can for the restaurants too. So they'll get the order, they'll prep it. Right now, we have zipline employees will go pick up that order, bring it over to our drone, put it in the drone. They have an app that they use to be able to tell the drone which order is in there. So the drone knows where to fly and deliver it to. And all of that is fully orchestrated in the backend. We are also now rolling out what we call our zipping points. And you can think of a zipping point as looking like a mailbox. And so the zipping point actually allows our partners to put the orders in themselves. So you don't need to have a zipline employee come and pick it up, put it in. So they'll go to the zipping point, punch in a PIN code, put in the order into that zipping point, close the drawer and

• 11:08Speaker 02

  walk away. And that's all they're doing. Again, on the backend, that then communicates with the cloud. We know this order came in, we figure out which zip can come pick it up. Then the zip, zip goes, picks up the orders, delivers it to the customer. And that really helps also get the time down and just how fast we can get these orders from being prepped into the customer's hands.

• 11:26Speaker 01

  Wow. So a couple of follow ups here. When we do talk about autonomous, like and fully autonomous, literally, how true is that? In a sense, like, is this autonomous flight vehicle is, everything is software controlled and this thing just gets its mission, I think is the terminal you just used. And from that point to the delivery of the good, and then I guess the return of the vehicle back to its base, I guess, that's all purely software driven, I guess.

• 11:54Speaker 02

  Fully software driven and autonomous. So yeah, there are no humans hiding behind a curtain with a joystick trying to control where the drone is going. That is all the drone. So the drone knows, it has its sensors to be able to navigate, to be able to de-conflict with other aircraft, to know if there are any health checks that it is doing and any results of those. So in all of that, fully autonomous, we have people who are more managing the fleet overall and just ensuring that the overall fleet is healthy and in a good state. There's a few different commands they can take, but the 99% of this, just the drones know what they need to do and they're able to execute that themselves.

• 12:31Speaker 01

  Yeah, okay. And then you've mentioned like the P2 platform, and I believe this sort of differs either from the previous platform or just a general image that comes to mind when we think about drones, that there's like this launch and catch system. Could you maybe just speak to that?

• 12:48Speaker 02

  Yeah, if you look at videos of our Platform One that is really operating internationally right now, you'll see that kind of launch and catch system. And it's really interesting when you watch how the Platform One drone works. Every flight, actually, it gets disassembled into four different pieces and then reassembled for the next flight. You can swap out a different battery, put in another battery, and you have humans involved in doing that. And that model's worked super well for our use cases that we have there. And we're still able to do thousands of deliveries a day on that platform. And when we look at Platform Two and what we needed it to be capable of doing, we're not talking about, sure, thousands of deliveries a day, which we're already doing, but we need to now get this to be millions and hundreds of them, right? Like, we want this fleet to be capable of million deliveries a day and more, and to

• 13:30Speaker 02

  do this all really at scale extremely quickly and safely and with that high precision. And so what we wanted to be able to do for our customers was just very different than what our current system was doing. And so with that, it meant we needed a different design of the drone. We needed to think about it from the beginning as being a very autonomous, safe system that can charge itself, that is fully contained in that way, and can operate in much more urban areas. It can deliver to that high-precision area, so we can deliver to people who have very little space in their yard. And we took a lot of lessons that we learned as we did as come to your Platform One and designed the drone, and we've flown millions of miles on there that we could learn from

• 14:14Speaker 02

  the design decisions there. And there are still essences of that in Platform Two, but ultimately, like, the use case, what we wanted to be able to do for our customers was just so different.

• 14:23Speaker 01

  So I think you were saying there's a launch and catch was key one, is that right? And then what is, I guess, the mechanism change then for P2?

• 14:31Speaker 02

  Yeah, so for P2, what we have are, we call them our towers and docks, for example, because it looks like a tower with some docks on there. And so the zip is sitting in the dock, and that dock is a charging station. So it'll charge the zip as long as it is sitting there. When the zip takes off, it does a little maneuver away from the dock, goes, picks up the package, and delivers it to the customer. And then when it comes back, it just simply goes and re-docks and charges. And so our dock structures... We're actually just rolling out now with our 12 dock structures and our idea with this is we're actually going to really have them be behind the scenes. They are going to be charging infrastructure that people don't really ever see. They're more in the back areas where like it's there's not foot traffic or not around those.

• 15:13Speaker 02

  And all you know is that the zip just came, picked up its package and delivered it to the house. But where they are is actually just charging on these towers, waiting for their missions.

• 15:21Speaker 01

  Okay, very cool. Let's talk about like you did touch on it in terms of fleet management. And I think the scale here is something that maybe isn't even understood yet, which is Zipline has actually, to my understanding, like flown like 130 million autonomous miles already. I'm sure that number is even even higher perhaps than that number I've just pulled. So I like no injuries and all this kind of stuff. I think it's just trying to understand, so let's just hear, what does that fleet number progression look like? And mainly, how are we to sort of look at what things break when you scale fleets like this? Cause like, again, when we think about software, I think a lot of listeners today can probably think through

• 16:03Speaker 01

  what it looked like for them when they were scaling a more like a SaaS platform, a very simple, like zero hardware involved SaaS platform. Oh, we had 100 users and then when we got to 1,000, then we got to 10,000. And certain things moved around and that was understood, but like this feels completely different when you're going through these numbers. So could we step through that?

• 16:21Speaker 02

  Yeah, it's a really interesting space. And I think especially when it comes to and that hardware in the real world tying into the software aside is always such an interesting place to be. And then taking a step back from this will say like, it feels so similar to when when I was at SpaceX and we were launching Starlink. One of the first things that my team was doing there was we had our two test satellites that were up in space. And we went and sat with the satellite operators and we looked at, how do you actually send commands? And it was a very simple web interface that an intern had built at one point and it worked for that. But then we thought about where are we going, right? And like, you're going to have thousands of satellites. What do you need to build to actually be able to manage that fleet? And you can imagine that's how that's grown, the systems you need for that.

• 17:04Speaker 02

  And I think we're at the same place at Zipline now where we have Hundreds of drones, but like where we're going, we're going to have, we're going to have the biggest fleet of aircraft in the world. So how do you think about the systems you need there? So we are really designing this from where you move from a world where you think about drones as snowflakes. Right? Each one's a little different. You understand these drones and you have to move into a world where your drones are more like cattle. Like you manage them, but like each one is not special on their own. So that means the systems have to be incredibly smart to understand how to reason about each one and surface what is needed for humans. And so we're building out a network operating center, which will really show you the health of them, the any ZIPS that might have any alerts coming up.

• 17:49Speaker 02

  We have the ZIPS actually telling us when they need to be out of service. So if there's something going on, like the ZIP will take itself out of service and surface that to us. So that way we can have maintenance go look at it if needed, or we can run health checks on it to reboot it and get it back up. But we want to make sure always safety first. And so that's the important thing with these systems is designing that so you can really reason about a fleet and not just single drones. And I think as we're expanding to more and more metros and we're expanding not just nationally, but then globally, you're also thinking about how do I now surface this in terms of the level of detail that you need, because at some level, some people will want the detail of specific sites.

• 18:30Speaker 02

  People want the level of detail on metros. People want the level of details at a state level or a country level. And you have to think about like, how do you build your systems to be able to show that the most important information kind of top of mind? So we can ensure we're giving the best customer experience. We have as much capacity as we can give because we are getting quite a lot of order volume. So that's really important for us and that we can also get ZIPS back up in service as fast as possible.

• 18:55Speaker 01

  Do you have any kind of like, I don't know, main example that comes to mind, like something that really did just break when you move from say the five first prototype or they're in production, I guess, but the five main precious aircraft, I mean, you moved to this cattle analogy. We can't be so precious about these because the volume of flying is more important than, I don't know, the quality of the trip exactly, something to that effect. But what broke in that process or something that broke, I guess?

• 19:25Speaker 02

  I think for us, the important thing is that we always do still have that high-quality, high-safety bar, right? So what really was an example of something that broke was when we had five, 10 drones, you can have people monitoring each one, looking at the telemetry coming out from each drone, looking at the logs after each one, just being like, oh, were these missions okay? Like, how did they go? This one seems odd. Let's take this one out of service and like, go inspect something there. And as the fleet grew, obviously, like, that was not sustainable. And so we definitely saw people getting overwhelmed with just being like, this drone's not doing anything. Does anyone know why? Right? And if you don't have the tools you need, yeah, so we built out what we call an auto discrepancy system. And so we were able to hook into the alarms that we have on the zip software side to say, if this alarm is going based on some threshold.

• 20:10Speaker 02

  So we built a configuration system that you could set this alarm, this threshold, how critical is that? And when that alarm then hits, it fully is integrated into our maintenance system then. We built that all in-house, so we have the full control over these systems to then go and create discrepancies. And a discrepancy is something that will then take the zip out of service. You cannot send missions to it anymore. It's like, they're hard stop of being like, this zip is down. And so, once you have that, now, we could see firsthand which zips were down. Maintenance then had the immediate signal of saying, oh, it's down for this alarm. And now, instead of humans having to go and monitor it, it turned it around to say, well, now the fleet is basically monitoring itself and telling us when it needs something.

• 20:51Speaker 02

  And that's just one example of a solution that you need as a sales.

• 20:56Speaker 01

  Yeah, that's really cool. And I guess it's software, and I'm like, maybe brackets firmware that sits on these vehicles. Like, when it comes to actually the maintenance, I don't know, cycles, like, I'm quite into sort of traditional aircraft, if you want to call it that in this context, like, and obviously, the maintenance of aircraft is like, just such a huge part of what keeps them safe and flying every day. The software piece, I don't really understand maybe the software piece of traditional aircraft. So if we think of the software piece of these aircraft, what kind of maintenance cycles are we talking to manage? Again, like, thinking at the sort of fleet level.

• 21:30Speaker 02

  I think when you look at the maintenance software that we needed for this, obviously, there is off the shelf products you could get for maintaining aircraft. It's very different type of use case than what we're trying to do for drones, which are very, you'd say, small aircraft compared to what you would picture. And since our model is really about something that's much more configured to what we are building, and given that we do fully own the entire vertical of it, right? We know the manufacturing, we know all the pieces on the bill materials that went into this. We know any issues that it had, we had the full traceability. It just made sense to build our own then and to make sure that we were handling all the cases that we needed to. And this maintenance software, then, it not only has the discrepancy piece that takes aircraft out of service,

• 22:15Speaker 02

  it has all the tools that our maintenance technicians need to be able to get them back in a service. So you have work orders that you have planned for, whether it's scheduled maintenance or unscheduled maintenance, where they can see exactly what are the instructions? What do we need to do? Because since we manufacture, we also provide the instructions to maintenance. So like, what do you need to do if you see certain problems? And all of this, including the system, has gone through review with the FAA to ensure that we are also building for the safety requirements that the FAA needs us to be building for and handling all the regulations that we need to be operating in the US for that. And so a system where now not only is it the day to day operational system of the maintenance techs to be able to get Zips into service, is it also our traceability system?

• 22:59Speaker 02

  Because now you know exactly what were the problems, what was the work done? Which parts were swapped? How many flights parts have flown on? So we make sure we never overfly parts too, because every part has our own life limits on that. And that ties directly into our manufacturing system that we have built ourself too. So we know what it has gone through even before it gets into commercial. So that's examples of that system.

• 23:21Speaker 01

  Yeah, well, moving on to the software that actually drives your operations to make all this work as well. And you did actually, I think, talk beginning about building an ERP inside SpaceX. And I'm aware that within ZipLine, the same has happened. Again, and I think this is really interesting, like building an ERP from scratch. This is not something I think that most companies would do. So very often, I'm sure many of our listeners are familiar with the term build versus buy. So especially nowadays, most companies, they need a bunch of software just to run their company, whether their software themselves or not. And oftentimes there will always be this question, especially at a certain scale of like, are we buying this in?

• 24:06Speaker 01

  Or are we going to build it? Or like, did we maybe build a version of this and now that's not scaling? We should just go buy off the shelf, someone who does this bigger than us, for example. So talking about ERPs, first of all, though, I'd like just to make sure we have to have a very diverse listener base when it comes to ages and all sorts. So let's just define an ERP to begin with, and then let's hear the story around why you thought with Siply it made sense to actually build one internally.

• 24:34Speaker 02

  So an ERP system, enterprise resource planning system, is the different tools you need to account for your inventory, think through your supply to manufacture. It's all the applications there. So you have procurement, like purchasing applications, warehousing applications, finance application, like all of these things in one. And the important thing, and I look at build versus buy decisions, and you're right, that is pervasive, right? Everybody has the same question, the same problem, is what I've seen is when you build your own systems for the areas that are your core competencies as a company, that gives you such a competitive advantage.

• 25:15Speaker 02

  If you look at SpaceX and Tesla and what they've done about like building all those internal systems, how do you manufacturing? Like at their core, they're manufacturing companies. And so to be able to build the system there, now you can design the process that you know is the best, because you can change the systems to match that process. When you buy systems, you have to change your process to match the systems. You don't have control over those, and that really limits just like how far you can go. And so I don't think you should build every single thing, but you should look at your company and say, well, what are our core competencies? That we would really benefit from being able to build custom from, and what are not our core competencies?

• 25:54Speaker 02

  And let's not build those. It's great products, we could buy for those, but these other ones really can enable us to go so much faster. And that's when you look at ZipLine, I talked about it being a little bit of this vertically integrated company. I think that is such a huge advantage we have. The fact that we do build all of our infrastructure ourselves, we build all of our drones ourselves, that manufacturing is so key to this company. It always has been from like Platform 1 to a Platform 2 or with everything we are going. We have great teams who understand how do we really design these drones and infrastructure to really be safe and low cost and to be able to scale where we're going. And so it made sense to say, well, we should just build

• 26:36Speaker 02

  the systems as well to ensure that we can build them as quickly, as cost effective, as safely as we can and have all of that information. Because one of the challenges still when you buy ERP systems, I think you'll find that companies tend to not love the part where data is not fully integrated across all of it. Sometimes we'll go to one application, you'll see stuff there, you're like, I wish I had this data in this other application, but now I'll have to re-enter it over here to make sure it's there too. And which one is my source of truth? And how do I? I just wish they were connected. And that's really the thing I see from building our own ERP system. You're really building all of this to be integrated fully together. And so that's when, say, like, hey, we know from manufacturing our full traceability of that. We know any issues that happened.

• 27:20Speaker 02

  We know our end of line test results that came out of that. By the time this goes into maintenance, it's not a separate system. They're all integrated together. So you have all of that information. If we were to just buy our own, buy an ERP system and try to build or buy another maintenance system, you're now spending all that effort trying to figure out how do I connect these two when their data models could be very different and not really have a great way of doing that. And usually if you build those kind of integrations, you're spending most of your time just troubleshooting why certain data didn't get to where it needed to be. And when we can own it ourselves, we're able to manage all of that and build it in a way that the data model from beginning to end does make sense. And so I was really excited that. ZipLine chose to really invest in this space. I think we're already seeing huge dividends pay off from it.

• 28:05Speaker 01

  Yeah, I, in a past life, helped a company, so Oracle, for example, is ERP provider that I think a lot of companies would maybe look to. And I wasn't super familiar with ERP systems at that stage. I just knew like, well, some companies use them and we were providing software more for like the consumer end piece. It was just this light bulb moment where they had kept telling me, well, but all the data's in the ERP. We just need to quote sync over to the consumer bit. And I looked at it, the two bits and said, well, you do realize that the way you structured the data in the ERP, it's like almost impossible that you're going to break out. We're taking line items and you say, okay, well, you've got this like parent line item, but you haven't broken it out into the four variants. So if you want to push that through to the end stage,

• 28:48Speaker 01

  you have to go back and redo your whole ERP basically to make this possible. And they couldn't get their head around this. And then the penny dropped with the person on their side. And to me, that was just a huge, I was like, wow, you can be a company and buy an ERP and be led maybe through by Oracle experts in that example, and yet still come out with the wrong solution in the end and be left with this. And if you just, I'm not saying maybe building in their case was the best solution either, but they probably would have ended up at least with the right solution if they built it as well. So, and in this case with ZipLine, it's like there must be just so many complexities in terms of data modeling, I imagine.

• 29:23Speaker 02

  Yeah, I think you described exactly the problem that that people face a lot of the times. And I, I think ERP companies, they do their best at really building great general solutions for companies. And for some companies, like those will work really well. The challenge is when you have the more bespoke company or the more bespoke way that you want to work or you want to manufacture or how your, your variants are, right? That becomes more challenging to figure out, how do we make this general model work for this? And by the time, when you get through the implementation stage of it, a lot of times your company may have already changed. Like, well, no, it doesn't work exactly how we need it to. And then you try to figure out, yeah, how do you just push them together? And so that's not usually the most fun part for engineers to be looking at.

• 30:06Speaker 02

  I don't think it makes sense for every company at the beginning stages to build these things. Now, ZipLine used a different ERP system for the majority of the time. And it wasn't until, you know, we really wanted to get into this scale manufacturing side of things. Where he said, hey, now is the time that we should look at building our own. So there are different stages companies go through and to make the best decisions for that. And it's, it's interesting because I think, you know, you described like, yeah, you didn't know what ERP systems were. I didn't know what ERP systems were before I started working on them. I think they sound. Boring in that way. And it was never my dream to go work on ERP systems. What I realized working on them, they are actually so key to how a company can function and work and be

• 30:46Speaker 02

  efficient at what they are doing. And the power of having good systems is huge for companies. And like my passion has always just been building software that solves problems for people. Just love when people are like really frustrated. I don't love when they're frustrated with something, but I love seeing when somebody is frustrated by a process, a problem, something. I know we can build software to help with that. We can build applications that'll just make that better. And when you see people using that and just all of a sudden now being like, this is so much better. This is so much easier. I now have all access to the data I need. It helps me make decisions faster. And I can see the impact of that. That's so fulfilling. And a lot of times ERP systems are at the core of that.

• 31:25Speaker 01

  Absolutely. I've also met someone who works in hospitality and like he had moved from a company that did have an ERP to one that didn't. And their reasoning to begin with was cost, which is often, an Oracle, for example, is six figures potentially. And yeah, just that mental shift of to go from not having an ERP to having to go back to spreadsheets. He just couldn't fathom that. And I think he did manage to convince to get the ERP implemented, but it's just this sort of fundamental data and process layer that so many companies need and just seems crazy that you try and operate with that one at a certain scale. So.

• 31:57Speaker 02

  Yeah, I think that is right. And I think that's, you know, to me, I look at it as like, it's also not just an ERP system. It is all your custom software that we're talking about building. They all get very tied together in this way. So even, you know, you talked about like, what happens when a customer places an order and the systems behind that? I mean, even if you think about the orders coming in, they need to know about the ZIPS to be able to then send the missions and have all these backend services together. So it's still tied to the fleet that we have. And so the fact that from end to end, we are building out both backend systems, but also front end applications. So that way we can, we can manage certain things about our partners or the fleet or about ZIPS or any of those things. And when you can build all this software in a very standard way with standard tech stack,

• 32:39Speaker 02

  a standard patterns, it suddenly just becomes so much easier to continue to build applications for what you need when you see problems. Instead of going to more spreadsheets, you can now think about, well, actually, I already have these systems that have three quarters of the data in there. I could just spin up another one. And then how do I think about how that fits into this whole puzzle that we're building? So it is important still to think about the systems that we're building. I think ERP is one part of this, but it really is just this, this platform that you can then leverage into then saying, how do we build custom software for this whole end to end process?

• 33:12Speaker 01

  So talking of building custom software, I think one that I was super interested to think about when I knew I'd be doing this episode was just this idea of most software developers, we understand the concept of like, you've got a dev environment, you know, push to staging and then try out there and then push to production. And that just seemed, I'm just trying to visualize, how does this even work in the world of autonomous flying? And I'm going to take a guess, there's maybe some like simulation that has to be part of that process because loading this on to an actual aircraft for, say, staging, maybe that works, maybe that doesn't. And that's kind of what I want to hear about. Like, what is that process? And like, how does a, maybe fully understanding that, like,

• 33:54Speaker 01

  for example, the ERP is the piece of the puzzle and it's fully integrated, but maybe looking at specifically the software that does actually have to run on vehicle. How does that look when it comes to like a dev process?

• 34:06Speaker 02

  Yeah, so I think there's two major pieces. And so I'll touch on one and maybe go more detail on the other one, because one of them is more of the software that actually goes directly on the vehicles. And that is more of the autonomy, the flight software, embedded software side of the stack. With all of that, there, we have a release cycle. About every six weeks, we'll cut a release, we'll test that very heavily, both in simulation as we're developing on that, but then also at our test sites. And I mentioned like, safety for us is top priority. And so we have a certain set of validation that it has to pass before we will start rolling out a software release into commercial. Similarly, where Rice and more on. The cloud and application side, we have software that is directly integrated with the vehicles. And we have software that is not at all touching the vehicles.

• 34:52Speaker 02

  And so the validation story there is it's a little bit nuanced because it depends what you're working on and how mission critical something is. And the way I think about things is if there's a human in the loop, you tend to not need as much verification as if there is no human in the loop. And so that's how you can think of different software. And in that sense, like we have similar to what you're saying, right? You have your dev, you have staging, you push to production. We have, we have those pieces of what we have, we call an integration environment. And that is specifically for our test sites. So we can push software there to our test sites first and actually test with hardware in the loop. And we've even set up a commercial test site, if you will, at our test site. So it operates exactly like commercials. So we can try things internally before, again, we impact any kind of customers with that.

• 35:34Speaker 02

  But we are also now at the some flexion point that you can call there, where with how the fleet is growing and how we're scaling, we now need much more of a simulation on the cloud side too. So we've had a simulation engine and we've built one out more fully now for the autonomy and like software side. On the cloud side, we, we're building out a fleet simulator to simulate all the different parts of an order from like order to delivery. So we can actually test that with the scale we are going to. So if today we're doing 3,000 deliveries a day, but we know by the end of the year, we want to be doing, let's say 25,000 deliveries a day or 50,000 deliveries a day. I want a system that can test that, right?

• 36:16Speaker 02

  I want to simulate that we are doing 50,000 deliveries a day because I need to stay way ahead of that curve and see what services break. And so we're now building out that simulation platform to make sure we are testing all of those services at scale.

• 36:28Speaker 01

  That's like effectively load testing, but there are no playbooks for this, right? In terms of autonomous and again, building just, I'll just call it regular software, load testing. There's so many platforms out there now that are like, you can just plug in a load testing platform. But yeah, I imagine this is like, there is almost no buy option on this, right? This has to be another build, right?

• 36:49Speaker 02

  Yeah, it's really tricky because it's like, you want to simulate your services or something soon too, but then we. Also want to simulate our zipping points or humans or what those process are like. And we want to simulate our zip software that we have also, so we can play it all together. I think that's where if you buy a product, I think you'll spend almost just so much time to try to configure it to make it work. Then you would have just building something. And when we build software, like we try to build it very iteratively, right? So you like build a piece, see if that works. You have one service running in it and then you start building the next pieces of your simulation platform. You get more services in there. And so it is definitely a continued approach to development with it.

• 37:25Speaker 01

  Moving on to, I guess, the actual human bit of this, which is the team and teams that do build all of this software. How have you thought about structuring those teams? I'd like to get also on to just what does effectively like incident response and being on call and all that kind of look like again in this context? Cause it probably looks a little bit different. But you know, especially, I guess, you've seen how it was all done at SpaceX. And like I read a bunch of books around how that maybe looked different there to say a lot of other companies. And that's why they were so successful in these big mission that they had to go with. And I imagine it's a little bit similar here. You've had to think about building software teams, maybe a little bit differently. Yeah. And I just kind of want to want to hear about that.

• 38:04Speaker 02

  There's a lot of ways where it looks similar in some ways where it definitely looks different. And I think when I look at how to really build software teams, I think making sure that people can really focus in some domain, have a lot of autonomy and ownership in that space, understand it deeply to figure out what needs to be built is is key to happen. It's really high performing teams. And when we're doing this, we make sure the engineers are also responsible for the product decisions too. Because then they can be really close to it and understand with stakeholders, with customers, whoever is using it. Like what is the problem? How do we then build a solution that solves this end to end? And so it structured the team to have three big areas. There's the commerce platform around the marketplace side that we're building.

• 38:47Speaker 02

  A lot of the the integrations with our partners, merchants, with healthcare partners can be all on that side. You had the delivery network that is more around like how we orchestrate with the fleet. How do we always reason about the state of the fleet? The the mission processing, like that side that we've discussed is is. In there as well as the maintenance side to just make sure you have a healthy delivery network and you have your enterprise system side, uh, which we've talked in depth on. So all of these is to be able to have enough depth within a team to keep it small enough where you understand that, but also really to be able to have quite a bit of ownership of, of what you're building. And when you, you touch on incident response, one of the challenges as we are scaling, in some ways, incident response can, can look similar.

• 39:30Speaker 02

  Sure. Yeah. You get paid, you go, you figure out what the problem is, you fix it. Like there's, there's that. But as we're scaling, we're now seeing like, how are we building our systems to ensure like, we don't take down, for example, all of commercial. All right. Like if we are operating everywhere, you now have to think about like, how do you, how do you charge your databases differently? How do you have a disaster recovery plan? How do you think about operating in multiple regions and how you structures? How do you release software to have canaries and be able to roll back? Right? So you have all of those problems that in, in other industries, you will have similar problems like that. It's just, I think the, the tricky thing always in ours is you also now have hardware in the loop as part of that.

• 40:10Speaker 02

  And that always adds an extra layer there that in your traditional like SaaS companies or just pure software, like you don't, you don't have to think about that.

• 40:18Speaker 01

  Is there like a sort of skewing in terms of the makeup of the team that has come in so far that have already had some aviation background? Or does that not really actually apply here?

• 40:28Speaker 02

  It doesn't really actually apply. We have software engineers, some of them who have been passionate about drones. That's always a nice connector for people to be like, I want to work in, in this space, but it's not, not at all a requirement. And that is saying like, we are building out this team of software engineers because there's so much we have to build. If you think about the scale of what I'm just describing that we need to build towards and all of these systems that we have a lot of zero to one still to build while we're also building them for the scale of what we are having today and what we plan to handle in the coming months and years. There's so much to do that. We are looking for like great full stack software engineers who can really jump in on building out these applications, these backend services to be able to do all that.

• 41:09Speaker 02

  And when I talk with with software engineers, what I'm really looking for is is that kind of ownership and that kind of curiosity and passion, just be like, I want to solve hard problems. I want to think about how to solve those. I want to own that end and I want to be really close to customers and have an impact with what I am doing and see that impact. And I think that's where we see the most successful people at Zipline, who just thrive with that kind of thing and that kind of ambiguity. And so to me, it doesn't matter like what language you've used in the past and which domain that you have worked in. It is just like, do you have that kind of curiosity and passion and hunger of how do I solve these problems and build robust systems for that?

• 41:50Speaker 01

  I always hate getting asked this question because it's sort of like, why are you asking the question? But I think in this case, the size of the team, I think that's interesting. If someone's coming into this industry where it's already a new industry, if they're going to join into autonomous vehicles, but like, are we talking 100 engineers? Are we talking 20? Like, what does it look for them?

• 42:06Speaker 02

  If you look across Zipline, we have a few hundred software engineers, but that is across the autonomy, embedded, flight software side of things. I'll say the majority of engineers actually sit there within the application or cloud space. Be closer to 40, 50 software engineers. It's not a, not a very big team and that's on purpose. Like, we know we need to grow, but we also are trying to be very thoughtful with this. A lot of the time you can build so much faster when you actually have smaller teams, as long as you are giving them that real ownership and focus. And that is still something we are working on at Zipline. We have so much that we want to do that we want to do everything. So how do we really narrow down to what we just need to be able to execute on on really well?

• 42:47Speaker 02

  And so regardless of the whole organization side, we want to make sure our teams are working in even smaller groups than that. Because I think like, you know, if you think about the times that people have done their best work, and in my experience, it has been like when you're on a team of two to four people. And you just have this ownership of just like getting these things completed. You know what does success look like? How can you help there? That it's you feel you can move so much faster than if you're on, you know, a team of 10, 20, 100 people and you're responsible for just a tiny part of that. And so even as we grow and as we scale, and we'll always keep that in mind, it's like, how do we keep that kind of size? Where you just feel like you can make those decisions?

• 43:26Speaker 01

  Yeah, absolutely. Literally, just as we're recording today, something's just shipped where I work and I've, I mean, I work it across a few projects, but one specifically, it was pretty much just me and one other person, an engineer and me. And it's so interesting when you have just these two people and you can just ping pong, ping pong. And this thing is going to go out to, you know, quite a large scale, but it is so interesting how actually some people might think that was a 20 person project. It was two. And that's, I think, as you say, I think that's where some of the best work is done. So it doesn't particularly matter like what the total size of engineering is per se, but it, but sort of how it then gets distilled down into like the team sizes, I think is super important. So that's good to hear.

• 44:03Speaker 02

  Yeah, I definitely picked up a lot of that and learned a lot of that from SpaceX. You know, there was a time that we were building out our, some of the warehouse management side for Starlink, knowing where that was going to go and scale. And went to go talk to this other company about it and they had a team of 40, 50 people. And they were like, well, how many people is on your team? And we kind of looked at each other, we're like, what's the two of us? I'm like, well, there's like a half engineer who couldn't make this trip, but just us. And that was okay. Like we were able to build it out still and what we needed. And I think like, when you do that, you're really forcing yourself to think about like, what is the highest priority? What is the highest impact thing I can do? Because we don't have all the bandwidth and all the people to do this.

• 44:43Speaker 02

  So you have to make sure you can ruthlessly prioritize and get down to that MVP and being like, how do I just build the next thing that I know will make a huge impact? And so we, you always have to balance, like, how do we keep growing to make sure we're not so lean that we can't actually get stuff done? But also that we don't become so bloated that you just end up working on things that are actually not useful.

• 45:04Speaker 01

  Yeah, for sure. As we start to like land the plane of the episode, so pardon, I guess, completely intended today. But if we look at where is ZipLine specifically going? And I guess where do you think that drone delivery generally is going? You know, because if we sort of loop this back to the start of the episode of where did ZipLine started in more rural communities, I think, in developing countries. And obviously, we've now progressed through like it's hitting metro areas in cities and so forth. Where does this go? Like, how far does the web of autonomous deliveries, where does it go country wise? I guess just geography wise overall, I'm just interested.

• 45:42Speaker 02

  Yeah, I think if you you look at just generally where the world is going today, there's so much more investments being made into the autonomous space because you're starting to see both with how AI has grown, but also just with what we can accomplish now is huge. And I think people are always looking for like ways that they can save time in whatever they need. And I think ZipLine plays directly into that. And so with autonomous delivery, drone delivery, you'll start, you see more companies trying to enter that space. And one of the reasons I'm like, obviously very bullish on ZipLine is because I think we approach it differently, where we really think about this from the customer first side of things. So if you look at our drone delivery, like our drones stay 300 feet up

• 46:24Speaker 02

  in the air, they're very high. We want to keep that noise as quiet as possible. We're always looking for ways to make that quieter because we know that's something that's really important to the communities that we do deliver in. And then there's a drone that comes down and just nicely puts your package on the ground. And I think when you see this, it feels magical. And what I love is seeing these videos of especially kids, it's close to my heart, but seeing kids see these deliveries and just be inspired by it and being so excited and seeing that parents love it too, right? Like adults are really thrilled by this. And I think if you look at some of the other players in the space, it is louder or noisier and not as of that customer first type of thinking. And that's something that I'm really

• 47:07Speaker 02

  glad that we're doing because with where we're going and how we're going to scale, we see this, we have tens of partners right now in our market. Place we're going quickly right now to hundreds. Every day we have new restaurant partners that are on our app. We are going to be expanding into a couple of different health cares this year, more healthcare partners next year. So we are quickly going to the place where we are now to in a few years being at a million deliveries a day, which is still a small slice of the instant delivery market. But being able to change the way people think about delivery and how often you could get it, or how fast you can get, or how easy it can be and how it just fits into your life where you don't even notice, but just what you need shows up. I think it's going to be so big because then not only nationally, but we're going to be doing this internationally too.

• 47:51Speaker 02

  That to me, you know, zip line really is at this point where we are revolutionizing an industry. There's only so many times that you get to do that in your life and I feel really lucky to be part of this and where the scale is really going.

• 48:03Speaker 01

  I like, you know, when you talk about, for example, how quiet vehicle can be and like customer centric. And it's also kind of environment centric as well because, you know, if people see a device like that landing, let's just say in their neighbor's house, but it does give a certain sound or something. They say, oh, well, who the hell is this company dropping into my neighbor? I don't want anything to do with them. But if it's something where they go, oh, wow, that thing is like so quiet. I never even realized it was there until I just looked up because I live in high rise in Singapore. And it's actually an area where people will just fly like recreational drones a lot. But the pitch of those drones is so high and quite disturbing actually, that I get quite frustrated at these drone flyers like, oh God, could they not fly them somewhere else?

• 48:44Speaker 01

  But then by focusing on the sound piece, that's huge. That's really great to kind of hear that. So.

• 48:50Speaker 02

  Yeah, I think that is one of the front of mind things always in in our approach of this is just working with the communities that we are in, hearing feedback from customers or not customers, the neighbors of customers, hearing what they are seeing. So we can keep making it better and better because when you do something like this, it has to just fit seamlessly into people's lives. If it is more of a nuisance, it's not going to scale and it's not going to win. And like we see this as something that really could just enhance people's lives. And so we have to make it that.

• 49:18Speaker 01

  Well, Kyle, it's been great to have you on. This is just obviously an area of technology that is only going to increase as we've talked today, but I think just the fact that it's probably one of the first times we've really talked about it in any kind of depth on Software Engineering Daily is just great to have done this. And yeah, we're going to be following ZipLine, I think, very closely. Where is best for people to look up ZipLine or like obviously a lot of software engineers listening, if they're being inspired and want to like think about applying for jobs, that kind of thing, where's the best place to go?

• 49:48Speaker 02

  You can go to our website and look up ZipLine. All of our roles are there. Look up software engineering roles. I'd be very excited to have listeners of this podcast come and contact us. You can also experience ZipLine. Right now, we're really serving mainly in Dallas and we'll be expanding to other metros soon as we talked about. So you'll see this more happening more and more. But if you find yourself there, download the ZipLine app and check out our delivery.

• 50:10Speaker 01

  Amazing. Thank you so much. And yeah, I'm sure we'll catch up again in the future.

• 50:14Speaker 02

  Definitely. Thanks for having me.