Welcome friends! I'm Jared and you are listening to The Change Log, where each week we interview the hackers, the leaders, and the innovators of the software world. On this episode we are joined by Zipline Co-Founder, CTO, and Product Architect Keenan Weiberbeck. Zipline is on a mission to build a world's first logistic system that serves all people equally via their fleet of autonomous drones that started in Africa delivering medical supplies and can now deliver packages up to 8 pounds directly to your doorstep.
They've solved a lot of gnarly technical and regulatory challenges along the way. We go deep with Keenan, I think you'll find this fascinating, but first, a big thank you to our partners at Fly.io, the public cloud built for developers who ship, we love Fly, you might too learn more at fly.io. Okay, Zipline on the Change Log, let's do it! Well friends, Agentic Postgres is here, and some of our friends over at Tiger Data.
This is the very first database built for agents and is built to let you build faster. You know, a fun side note is 80% of Claude was built with AI. Over a year ago, 25% of Google's code was AI generated. It's safe to say that now it's probably close to 100%.
Most people I talk to most of the people I talk to almost all their code is being generated. That's a different world. Here's the deal. Agents are the new developers.
They don't click, they don't scroll, they call, they retrieve, they parallelize. They plug in your infrastructure to places you need to perform, but your database is probably still thinking about humans only because that's kind of where Postgres is at. Tiger Data's philosophy is that when your agents need to spin up sandboxes or migrations, curios volumes, a vector and text data, well, normal Postgres, it might choke, and so they fix that. Here's what we're at right now.
Agentic Postgres delivers these three big leaps, native search and retrieval, instant zero-copy forks and MCP server plus your CLI plus a cool free tier. Now, if this is intriguing at all, head over to tigerdata.com, install the CLI, just three commands, spin up an Agentic Postgres service and let your agents work at the speed they expect, not the speed of the old way. The new way Agentic Postgres, it's built for agents, is designed to elevate your developer experience and build the next big thing. Again, go to tigerdata.com to learn more.
Today we're joined by Keenan Weyrobek, founder and CTO of Zipline, a company I'm very, very interested and welcome to the show, the pleasure of being here. Pleasure to have you autonomous flying machines, all kinds of deliveries happening. I saw Zipline and I thought, you know what, this one makes sense. There's a lot of people trying to do delivery.
Of course, you have autonomous cars upcoming, and you have people that are doing tunneling, they're trying to put tunnels in the ground and ship it. Kind of a few traumas, but underground future drama. And then we have drones, which is the only one playing the drone game, but you guys are, I think, way ahead of the game, been doing it for a long time. Tell us about the start of this company and where you're coming from.
Yeah, so we started almost 12 years ago now, and we started with an Inesha Venetia of delivering blood to hospitals in Rwanda. That's where we started. Why there? Yeah, so really, Rwanda earned this.
We knew we wanted to start in health. My, with the very beginning of this, we started exploring the space based on really just stories from family and friends. My wife's an epidemiologist and she would tell me these stories about health intervention campaigns that we get stuck on logistics, right? These would be like vaccine campaigns where they had the vaccines, they had the doctors, they had, but then the logistics got in the way and they couldn't be successful.
And so yeah, that's how we started. Went deep on that. I'm personally not an early adopter. I'm a very tech skeptic.
So went deep in Central America and I forget the time expected to come away with a thousand reasons why we couldn't possibly make a difference. And the opposite happened. The deeper we went, the more conviction we got that we could make a big difference. And, and one of those, one of those places we were exploring with was Rwanda, and they, they turned out to be a phenomenal first customer for us, really a partner figuring this out together.
Yeah, and of course, why blood? It's just this rare commodity everywhere, right? There's never enough of it. It's actually very expensive.
We think of it as free because we donate it, right? But the cost of the collection, the testing, the transportation is very expensive. Hundreds of dollars a unit in places like Rwanda, way more in places like here, and it has a very short shelf life, right? It's a little seven days when time is donated.
It's a time expires if you don't give it to somebody who needs it. And so it's just by centralizing blood in one place and then delivering it when you know what blood type is needed for what patient what time it turns out you can virtually eliminate blood, waste, saving a ton of money and a ton of lives for the health system. That's why we started there. What's the tactical nature of that when you went to Rwanda?
Was it discovery first and then tech later? How did you come to a technical solution? How did you think about it before you built something? Yeah, I mean, we had built nothing.
I mean, we literally called a friend of mine who was going to drawing and he drew pencil sketches and built a slide deck of the concept. And we were using that to talk to people. Or in early days, it was just talking to, you know, the operators in these in these health systems that actually run logistics, run this testing, run these labs. But very quickly, we ended up having meetings with the offices of presidents in these countries.
And that was a big sign that we were looking at a problem that was a really big deal, you know, in these for these health systems. And yeah, no technology whatsoever. You know, a year or two before we were doing this, Amazon was like, hey, drone delivery coming next year. And so, you know, that don't delivery was like an idea that was out there.
It wasn't the real thing at anywhere. And so we kind of thought of ourselves as like, hey, you know, if we're going to do something, let's find a niche where the value is really high to do this. And yeah, no technology. And then of course, once the once and the interest was there, we got moving fast.
So was there a point that you and your co-founders looked at each other? You had saved countless lives with delivering blood around Africa and thought burritos. You know, burritos are next. Was that when they start?
It was it was both there and not there, right? In a lot of the countries we operate around the world, we start with health systems. That's how we started the United States, we started with health deliveries during COVID. And then expanded from there.
So in the islands of South Eastern Japan, we deliver healthcare supplies and bento boxes. And in a lot of places, in Africa, we operate, we started in human health and then expanded into various agricultural use cases, things like genetic diversity for milk cows, huge impact, but like super obscure. And we just were layering on other use cases and slowly worked our way into things like e-commerce and burritos. And what's compelling?
Like, but we think about supply. Like a lot of we talk about the impact on health, which is really exciting. We started with the impact of like blood, right? It's a super visceral, you know, the high impact, but very rare problem, right?
Most of us don't need blood transfusions in our life. But when you need it, you really need it. And then we fully worked our way in health to preventative care, which is actually where the real cost savings for health systems is. And then we've worked our way into other areas like animal health.
And one of the things that's really magical about this, you know, as we step into new things like auto parts delivery, right? Like, you know, what limits the mechanics ability to service cars is usually like how fast they can get the parts. And basically, like the way I think about it is basically for life at home, in the home or professionally, we're in the mission of getting you what you need when you need it. And we do it in a way that's not just fast, right?
We sleep over the traffic. We're very reliable in that way. But just, you know, wildly environmentally friendly. We don't talk a lot about that.
We can get that as interesting. Like, the, you know, we're talking about like a 20 X improvement in the overall environmental footprint of the supply chain and the almost every aspect, including things like bird safety, but it's like something we don't talk about a lot. So there's so many layers to this. Well, even I live here in Texas, we have a lot of wind farms, because you know, here in Texas, we have mulbleways at probably like Nebraska, Jared, you got multiple ways you're getting electricity.
And we, I'm not so much a fan of them. They're kind of like big and crazy, but I hear people get upset with the bird issue is essentially of that. And that, you know, to maybe to the environmental aspect of it, that there's still so much of a cost to produce even wind energy, that it's almost not worth it when you compare to, you know, how you talk about your efficiencies. Yeah.
And it's, it's, you know, this, I care a lot about birds, I pay a lot of attention to it. And yeah, we estimate that when we displace, you know, every by car, we reduce bird injuries by something like some routine 10 X and 100 X lower rate. So we study that a lot. And so, you know, there's a lot of aspects to why we do what we do and why we're excited about scaling what we do into all these different verticals.
So let's talk about the design of the drone itself, because we mentioned, you know, the tactical approach coming out of the need of delivering these things. And I wonder when I saw your guys design, I was very surprised by it. There's a kind of a more typical quadcopter, larger quadcopter looking thing, also like an airplane with blades on it. And then it doesn't actually do a delivery, it delivers the delivery mechanism, which is a smaller kind of a baby copter that comes down on a zip.
That's, for zoom, where you guys the name, it lowers it down to the ground and raises it back up again. Where did that design come from? Yeah. So that to that sort of double drone, drone inside of a drone design, it came from just an obsession to figuring out what would actually work for our customers.
So our first platform that does long range delivery has a lot of great attributes, but it requires, you know, about two parking spots worth of space to deliver in, because it literally just flies over, drops the package with a little paper parachute on it and floats the package, floats the ground. But so many of our customers in the health space and otherwise, we're like, we want home delivery, we want to in-metro delivery where you don't have that kind of space. And at the time, we're kind of like, well, we don't do that. And eventually that's enough time to start thinking about how would you do this?
And we knew from that platform that one of the things that makes people love our service is you don't hear our drones. And that's way harder than it sounds. And we're like, well, we don't know how to do a super precision delivery without hearing the drone. And if we've seen other ways of doing this, it's usually loud and noisy and kicks up a dust storm and takes up, you know, can't deliver very precisely.
And so this two part architecture enables a bunch of things. One thing that enables is quiet, it lets the drone itself stay up at 100 meters, 300 plus feet up in the air, which is one of the many things we do to make that just silent in even suburban places. And then that little mini drone that comes to the ground, we call it the delivery zip. It comes to the ground, you know, it actually carries it, delivers the package for you.
It has its own little, you know, propellers on it so that if it windy days and stuff, it can still be super precise and get into a tight space. And so really, those two things helping us be really quiet and be super precise, right? We can get into a really tight space without that little drone that comes to the ground while the big drone stays up high. That does the heavy lifting.
It's literally there to carry the weight, the distance. And that's why we have the whole drone inside of a drone solution. It reminds me of how you see things happen in space. You see like a little jettison engine sort of like pushing it and nudging it.
And I'm a sci-fi guy. So I see these filmed all the time. It's kind of like a little slight adjustments, but you just have, is it one single large propeller or is it multiple on the, I guess, the mini drone? What is that name for that guy?
Yeah, internally we call it the droid delivery zip. We don't have the great name for it. But we just call it the, yeah, I like deliveries. But anyway, those little things that come to the ground.
Yeah, it's actually got three little thrusters, very similar in constant. Yeah. One big thruster in the back and that's Ruster's job is to fight big heavy winds. And so like pointing the way to make sure it's going to blow off course.
And it's got a little bow thruster and a stern thruster. If you like boats, kind of think of it that way, that help it basically stay oriented and do the side to side adjustments as it's coming down and staying precise. But yeah, it's, we actually, a lot of our team comes from space and the control theory behind how you stay precise on that little delivery zip as it comes to the ground is very similar to how you think about reaction control thrusters on a spacecraft. Because I think can spill your coffee.
I mean, sure, I can flip a burrito, no problem. But if you're lower in a coffee down, like that's very, it has to stay oriented very well. I assume blood, they probably want that stuff spinning or something, but there are certain fragile items that can't go so on the software side, or a coffee, coffee is fragile. It is on the software side.
Are those two divergent operating systems? That makes it seems like they have perhaps different concerns, but they probably have a lot of overlap as well. How did you tackle the software side of these two different drones? Oh, yeah, they're very different controls problems.
Yeah, the drone up there's a pie, that you know, it has a wing, so to fly fixed wing on the wing really efficiently. It has a public and hover in place for takeoff landing and while it's doing deliveries. Yeah, the it's a long story that controls approach and it really comes down to just massive amounts of testing. You know, our high-lying test sites have done hundreds of thousands of deliveries.
We chase weather with mobile test rigs, so we go chasing like hail and ice and conditions and these kinds of things. You know, a ton of simulation, you know, literally half of all the engineering we do, it's applying is test, like just full on half of it. That's how we can do this is basically building the test systems, the various software platforms for simulation and things like that, the actual test scenarios, all the ground testing we do, we have an entire building down the street from where I am. That's all it is, is just hundreds of ground test systems to take to simulate what we do in the air on the ground.
Yeah, it's the answer to your question is a long one, but it's literally half of what we do is that's all the testing it takes to actually develop the control systems for these things to know that they're going to be both capable but also safe. I was thinking about updating the software. I mean, you mentioned the test facilities. I imagine do a lot of, you know, iteration there.
So you're constantly deploying potentially over the air updates. I have no idea how you accomplished that mission, but the version operating system and also a truly distributed update platform. How do you get new to the individualized is an operating system delivery? Is it an individualized delivery?
Can you talk about that at all? Yeah, absolutely. So we think about software and software deployment. There's sort of two worlds for us.
One we call, we think it was flight software and then cloud software. Flight software is all the pieces, some few parts of the cloud, but mostly things on the actual aircraft that we consider flight critical, right? And we were that software release process takes us about six weeks, every six weeks we release software to that system. And we do just in those six weeks, we do tens of thousands of flight tests.
We do a bunch of hardware loop testing. So these are like basically think of it as like the matrix where you take the electronics of the aircraft and basically plug it into a simulation, literally a fool it. So it thinks it's flying over and down somewhere, but it's actually, you know, over our basement plugged into the simulation plus of course software loop simulation where you're doing like, you know, millions of flight tests. And yeah, that whole journey takes us about six weeks to get to the point where we're like, yep, this new software is good to go.
And then we release it and then we have an over the air update system that updates all the process to software on the aircraft and and deploys. Yeah, we do that. People often ask that we do that in the air or not. It's like, no, no, when our aircraft are docked, they update themselves, they check themselves and they're like, okay, good software is good to go.
And then they'll fly again. How many of these problems are novel to you? I know that the defense systems that we have here in the US probably have these problems and maybe have solved a lot of this, but maybe you don't have access to the DODs tech platform or maybe lack thereof. How much of this is invented here and how much of this is, you know, maybe a partner or event that you bring in to support like over the air updates for example, way more of this is done in house and I would have ever thought we would have to do.
Actually, we started zipline. I was like, great, you know, I'm gonna go find somebody who has a drone, buy it from them, modify a little bit for deliveries and start serving our first customer. And the best quote I got back then from the companies making drones for defense was a $200,000 drone with a 200 flight warranty. If I did not fly in the rain and to be clear, most of these countries are rains pretty much every day.
So that wasn't going to work. Yeah, no, we do a lot in house and a lot of that because we fly in conditions that no one else flies in, right? Stormy weather near the ground or amount of stuff like that. Like you just know, when flies in that.
And so we've had to learn a lot of this stuff ourselves and fill our own basically data sets and experience and simulation approaches to actually develop these things. But then the other side of what makes this very unique is just the scale, right? We operate at a very large scale. And so like this, you know, over their updates as a good example where we need that to be very, very easy and robust in a way where if you're operating at a smaller scale, like a human can do a lot of double checking of that and things like that.
And it doesn't matter too much. So yeah, there's a lot of even over the updates system we built ourselves. Do you know how many drones are in your fleet roughly like worldwide to give us an idea of the scale you're currently at? Yeah, so it's a couple hundred.
Okay. And you just started the United States recently. Well, 2021, I think was the first non-medical flights. This is what I've been told by Ian behind the scenes.
And now you are in Dallas and really now I just saw a video from your CEO and co-founder that there's like a whole bunch of drones getting built right now to just go crazy. But yeah, 200 worldwide and how many of those are over there and we're wanting to do in their thing. I think it's close to 400 or so. So it's about 300 outside of our first generation.
And yeah, well over 100. But I don't think 200 yet of our next of our precision delivery, the drone of the drone system. Gotcha. So how much of your software is orchestration?
And I assume that's the cloud side that you referenced the control cloud. I guess maybe tell us more about the cloud side and what all that entails. Oh, there's a lot to it. So there's obviously the pieces for people to place their orders.
Every partner we have we have basically systems for to integrate with our partners data systems. Then we have our basically dispassioned. I literally think of this as like there's cloud autonomy or fleet level autonomy and then aircraft level autonomy. And at the fleet level, you have to decide like which aircraft is going to go on which mission at which time and some of that is based on which aircraft is capable, right?
That mission, some of that is based on making sure if we told someone, hey, we'll deliver to you in this 60 second window, then we actually dispatch the right aircraft for the right time, get the order ready at the right time so that we'll hit that window. And some of it is stuff that like people, you know, other cloud stuff for us is like weather forecasting, we do our weather forecasting. We can talk about that. It's a really fun problem.
But also like, you know, basically we have to design our own highways, right? If you think about autonomous vehicles, you kind of take for granted that if you want autonomous vehicle to drive from here to, you know, over the mountains that like you can find if you use the road that's already been designed, you'll get there. There's no such thing for drones. So we have to do a lot of computation in the cloud to basically give enough prior to our aircraft so that when they're flying, they have kind of the equivalent of a highway system.
It's not quite that simple. So that when they're doing a void in swine, for example, and planning that live that they're doing that with enough sort of prior that they're not going to get off track and not be able to make their delivery. And they generally fly at 300 meters, is that what you said? They fly about 100 meters.
So 300 feet. 300 feet. 300 feet. Thank you.
Yeah. What kind of stuff do you have to avoid? Obviously birds, but at that, I mean, cell towers, air strips perhaps like what's the kind of stuff that has to be avoided at that height? Yeah, for sure.
So yeah, you can have very tall cranes, cell towers. You can have inaccurate maps. So you may not be at the height you think you are. So there's hill or mountain there.
You, yeah, definitely other aircraft. That's a big part of what we avoid. There's not a ton of passenger aircraft at that altitude, but there are some and it's really important that we avoid them as well. That's the kinds of things we avoid.
Well friends, I'm here with a good friend of mine again, Kyle Belbraith, co-founder and CEO of depot.dev. Kyle, we are in an era of disruption, right? I would also describe it as rethinking. Well, we thought was true.
And I guess that's kind of the definition of disruption. But from your perspective, how are teams, reliability teams, CI, CD pipeline teams, how are they all rethinking things and where does depot fit into that? In the conversations that I have with customers, a lot of DevOps teams, platform teams, site reliability teams, they're really looking at this new era of software engineering that we're all living in. And they're starting to question like the bottleneck is no longer the act of writing code.
The bottleneck is shifting. The most time consuming part is integrating the code. It's everything that comes after. It's the build.
It's the pull request review. It's the deployment. It's the getting it into production. Once it's in production, it's scaling up support teams to support it.
It's adding documentation, all of these downstream problems. And so through the lens of depot, what we're really starting to think about is there's a very realistic possibility that within the next two to three years, maybe even sooner, that we're going to enter a world where an engineering team of three people could theoretically have the velocity of an engineering team of 300 people. And what's the consequences of that? What's the consequences of the code velocity spiking up to that level with such a small team?
There's no way three engineers are going to be able to code review all of the code that's being created if there's three engineers and 297 agents also grading features and fixing bugs. So that's just like from a pull request perspective. But then you think about it through a build lens too of if your builds take 20 minutes with three humans, and now you're going to have three humans and 297 agents also running. Well, like you definitely don't want to build sticky 20 minutes because now like the entire pinch point is the build pipeline.
And so we're starting to think a lot about how do we eliminate the bottlenecks that come downstream? And what can we do with Depot that streamlines that? So obviously friends, we are in an era of disruption. Things are changing.
You know what, I know it. That's how it is. And the thing with production and what Kyle's talking about here is how in the world do you get your builds to be faster? I get them to be more reliable, faster, more observability around those deployments.
You need it. It's required and Depot is there to help you. So a good first step is to go to Depot dot dev, get faster, try the trial is too easy. Again, depot dot dev is where to go.
It all begins at depot dot dev. How much does regulation play into this rollout? I assume every area probably has different rules about how you can go about flying your drones at your feet. Yeah, I wish everybody had rules.
I think that every like you've been, usually people say they want less rules when they're trying to scale up. Yeah, I mean, when you're startup and you go to a regulator and you're like, cool, I would like to do this thing. And they're like, well, that's not allowed. And then basically, from there, it's like all by exception.
And so you have to kind of work it out. All the rules that you operate at the detail. And as a startup, that's a slow process. And startups need to go fast to survive.
And that's why I said I wish there was a precedent. In some ways, obviously, there's some luxury getting to help create the precedent. But yeah, it's a lot of working with the regulators. Some things about air spaces between countries are very similar, like harmonized.
But other things are very different. And so yeah, things we have to do here in the US have been very different than Rwanda. Yeah, it's been a big part of what we do. But it's also we've gone from that being a big challenge, maybe 10 years ago to now it's something we've gotten quite good at and quite good at working with these partners and the regulators as partners and working with them, proactively enough that we can generally work out what needs to be worked out before we need to serve a customer.
But it takes a lot of effort. I will say that. Yeah, I was thinking of the luxury of not having rules that are already defined, because those can slow you down, but actually not having rules and not having a clear path towards engagement. That means you have the trailblades and the trailblades.
You got to get out of a machete and hack away a bunch of stuff, and that can be slower and more laborious than if somebody else had already cleared the path for you. So that makes sense. There's a great story here in the United States. Starting about six years ago, we started working on the sensor system on the aircraft that can sense and avoid other aircraft.
This is a system that uses machine learning. And machine learning is a class of software that the regulators have no experience with literally. And it took us about five years of working with them to go from the beginning of this to them approving us operate. And that was the first time I've ever approved AI, you know, ML based software for safety in the airspace.
And so it was near daily conversations with their teams figuring that out over that five-year journey. And there's some people at the FAA who and I'm at Zipline who I respect a ton for working through the minutiae, they had to work through to figure out how do you, what would the requirements be and how would you validate the system against those requirements and then actually doing all that work and all that analysis to bring it back to the FAA. Like, okay, we did what we agreed to. Like, let's go through this together.
And that was a five-year journey there. And it was a hard one battle. I don't mean like Zipline versus the FAA was very much in it together because they definitely wanted to figure it out too. Yeah, it was something else.
This is an example where the word regulation, which you haven't quite said yet, gets really weird. And I don't want to go into politics, but it seems to be the word that gets thrown around regulation, less regulation, more regulation. But as a developer, I'm really lean back on what you said there was not a presence of which was specifications, which is really which regulation is. It's an adherence to a specification that everyone's agrees on for obvious reasons, but you're in this kind of unique high stakes scenario where maybe regulation could be less pressure, and in your case, you got to be high stakes scenario where if there's a crash or if there's a break of leg situation, which I'm not sure you're like the word crash.
I wouldn't like the word crash if I was in your business personally. But I just think about the need for that. Can you speak to how that's played as an ally versus a foe? Yeah, I think there's a couple layers for how we think about this.
The first one is because everywhere we've been, everywhere we've gone, there hasn't been some like a sense of expectation to follow. We've taken the mantra that like our first job is to convince ourselves and not in like a hand way of your way. It's like, no, no, like, this is over our house, over our kids, like, you know, are we convinced that we've taken a rigorous approach before we suggest that approach to a regulator. And that's gone a long way, right?
It's that mind says attracting some of the best talent is figuring out some of the stuff that was really complicated. It's trying to attract the talent. We need to actually figure this out. And then it's also forced us to do the work, right?
To convince ourselves, the analysis, the, you know, all the testing, all the data review to convince ourselves is also what the regulators want to see, right? So if we've done that to ourselves and we've really been skeptical of our internally first, it helps a ton when you're then having these in-depth conversations with these folks on the regulatory side who are, you know, they have the, they have the like, you know, the completely thankless job of like, you know, okay, we got to figure out this specification for this new thing that no one's done before. And so right, like, you know, if they underdo it and someone gets hurt, they look really bad. And of course, like, if they overdo the regulation, then everybody in the industry complains of like, oh, they, you know, they wrote down these regulations that are completely impractical, right?
And so they have, they're stuck between a rock and a hard place. And so by doing that legwork up front and internally proving to ourselves something that we really believe in first and then bringing it to them, that's been the core from like, from our perspective. And then the only other piece of it that I would say is like, it's all relationships. These are all people on the regulatory side, they've got a job to do, we've got a job to do.
And so we spend a lot of time, you know, basically working together to make sure we understand what they're trying to do. They spend a lot of time working to understand. We're trying to do, be really open minded, make sure we're hearing each other out, like in any relationship and trying to make progress every day. Even if it's not as fast as you might like.
How would you frame this isn't an exact one to one, I say this, but how would you frame test coverage, you know, in terms of a coverage level, confidence level, when you ship something and it's in a regulation standpoint, or your specification to adhere to, is there like 95% 98, like what do you strive towards when it comes to adherence to a spec or to find in the spec? What is, what is confidence to your team? Oh, great question. So there's a, there's a, there's a, there's a, there's a model for thinking about this that was called the Swiss cheese model.
I did not come up with that name, although I'm known for naming things with really dumb names. It's actually a NASA name, the Swiss cheese model. And the way it's actually basically what it is, is it's like every sort of, every approach to testing is like one slice of your Swiss cheese, right? It's going to have good coverage of some aspects.
But if you look at it, it's going to have holes, right? For every, every type of testing you do, you obviously have many different layers of testing that you do. And intent is if you stack up those layers of Swiss cheese and look at them, you know, through the stack, then you're not going to see you through holes, right? If you're doing it well.
And we spend a lot of, so examples of our layers of Swiss cheese, you know, some of them are going to be familiar with things like unit testing and static testing and things like that that are commonly done software software and the loop testing. So this is where you have like full on physics level simulation running of your full system, even your full fleet. And you're able to write test scenarios on top of that. We talked a little bit about the hardware and the loop testing where you take the hardware itself, the brain of the aircraft plug into a simulator and fool it into the game.
It's in the real world. That's great for testing, you know, like the, the, the actual like hardware level components, like if you short out of a certain bus, does the actual full software stack detect that short and do the right thing? And then a lot of things in flight tests, we do all kinds of different flight tests. We do, you know, on the order of 10,000 plus flights a week at this point across our flight testing.
And almost every single one of those flights is, is pushing the system to its extreme and some play. We actually have this fully automated software system. We call chaos monkey, where basically what it's doing as we're dispatching all these flights, is chaos monkey is literally throwing chaos into the system as those missions are happening, that either will cause the airplanes to do something extraordinarily like dynamic against the physics limits of the aircraft or turning off some systems of the software, killing various rotors, things like that, and making sure that the system despite, in this given flight having dozens of weird things happen that off nominal events as we call them happen in that flight does the whole system handling gracefully and safely. And, and then this is just on the software side, right?
When we think about hardware, very similar thing, and many layers of testing of the hardware to make sure we understand deeply its performance and its reliability. Yeah, and there are entire teams of folks who look at all that testing and basically are constantly questioning, Hey, okay, we added it, we're in this release, we have a new capability, we're releasing, did we add enough testing to all the different layers of the Swiss cheese such that that that's going to be responsible to ship? And there are times we, you know, we think we're ready and we do that review of everything we did. And we're like, Oh, this isn't ready.
We're pulling this from this release. It's got to, it's got to, it's got more work to do just on the testing side, not to get that confidence. These releases, are they shares much to like you seem very sharing. I like this.
I think about releases and I think about, wow, if I released my test level from idea to new capabilities, you said, into production, there's probably several layers that are in that middle ground, which is like a true release, but not in a real real scenario. So speak, how do you play in releases? How do you graduate releases from tests, delivery, observability, testing, and potentially you said you do 10,000 flights a week, that's seven days in a week that's 1400 flights a day, roughly, gosh, it's a lot of flights. But how do you release and do that in a way that's like, okay, it's in production, it's not real production, I'm assuming these things.
So walk me through that kind of idea. Yeah. Okay. So depending on the scale of a given feature, I'll talk about one of the biggest features we ever released, we just released it recently.
So we talked about the drone that flies up high, it has a wing and can hover until about a month ago in our releases and our operations, we were only hovering, we were not flying on that wing. So we're flying it more like a traditional, you know, quadcopter, it's a pentacopter, but we've trying to find like a traditional quadcopter, just hover, which means the range is very limited. But while we were working on the, actually be able to fly on the wing and that's the software and systems to transition from hover onto fixed wing, what's for to the industry and then back into hover, including when anything could be going wrong, like any of those rotors could not be working and that kind of thing is, there's a lot to that. And we've been working on that for working on those features, you know, at some level of development testing for two years to enable this.
And so about two or three months before that release cuts. So I talk about releasing every six weeks, we cut basically the beginning of that six weeks, we will look at all the new features that folks think already for release. And we'll look at like, how tested are they? How proven are they?
How good is the test coverage and all these layers of Swiss cheese? And then we'll decide, okay, hey, this feature is ready, this feature is ready, now that feature is not ready, it's not going to go in this release and then we'll cut a release. And then once we cut a release, there's a bit of a stabilization that takes us about a week to make sure that release is stable. And then it goes into this very structured release campaign that takes about five weeks on average, which is, you know, depends on the release, but something like 50,000 flights, a whole bunch of hardware with tests and software with tests and all these other tests will we will do again as well as part of that release process.
And then all the people in all the teams are basically paying a ton of attention to all the data coming out of all that testing. And over the years, we've developed all kinds of tooling and dashboards that help all the teams look at that data and look for anything weird, anything that might we consider a near miss. Obviously, the real miss is if we have a parachute landing during that testing, we're going to know exactly what goes on there. But we're looking for anything that's at all weird, we call it a near miss and studying it and seeing if it's if it needs to be addressed or if it's fine, seeing if it sometimes we do, you kind of think of that flight test is like the last leg.
If we find something in flight tests, that's a red flag test, like, Hey, the other layers of Swiss cheese aren't good enough. So we find something flight testing that campaign, we're immediately investing in those lower those other levels of Swiss cheese making better and prove their coverage. And then only once the data says we've got a, you know, we've got a system that meets or exceeds the overall target level safety of our last release, do we then say this is ready to actually show? Do you have the idea of a black box in your, in your thing?
I mean, I know that airplanes do so I mentioned you got some version of a black box where if it does, I'm sorry, crash that you've got some sort of thing in there. And then I've also think about like observability because you got all this testing happening. And I think about like traditional software in the cloud is kind of easy to orchestrate observability. But you've got over the year, I'm sure you've got some version of Wi Fi or access to, you know, the thing digitally via a network of sorts, telemetry going, how does that black box is our black box and how does observability happen in those scenarios?
Yeah, so absolutely. So we log a ton of data on the vehicles at all times. And that's of course not at all this testing, but also in production. And that's, you know, the philosophy is that like anything that possibly go wrong or be a near miss, you got to study and you mentioned crashes, we mentioned we have a parachute system for the aircraft that's kind of the backup to the redundancy.
So there's a redundancy in the aircraft so it can not only fly when things don't work, but the backups of the backups of parachute, so it'll flip to the ground like it's actually made for us by a skydiving parachute company. So it's like a skydiving ground. And so yeah, if we ever have a parachute landing and tests or operations or anything that's even close to a weird data, like we go study that to basically deeply, deeply understand it, because quite often it's a new insight. We're so far in the long tail of the problem that many of the problems we see now, they happen 100s of thousands of flights.
And so you basically like if we didn't log it, think of it as like, Oh, no, we have to wait for this to happen again, 100s of thousands of flights, which is a total shame. So shame, shame, no, that's not the same. Shame is not the logging yet. So we log these things.
Now in addition to the logging to enable us to like go through those logs and understand everything that happened, we use those logs not just for like, we're causing a specific problem, we use those logs to understand the things in aggregates. And so we have tools where you can mine that those logs longitudinally, like across a bunch of, you know, across thousands of flights to deeply understand the statistics of a certain thing. That's really important as well. And of course, during live operations, yeah, the aircraft are reporting over over radios, like live what's going on.
We have a remote operations center that's monitoring all of that. And so during live operations, we have certain things that basically they are pilots, I think of them more like an air traffic controller where they can be like, okay, you go back and dock and that kind of thing, and understand what's going on at a very sort of fleet level. Have you ever logged a tornado? We've definitely, yeah.
So the closest thing we've logged, we've lots of tornadoes, some very small, I don't think you call them a tornado, and they're like the, you know, basically the things are too small to be considered tornadoes. And some of our testing, we're actually chasing some tornadoes right now as we look for hail and more extreme weather events with our mobile test rigs. The craziest things we have a lot of log data on is what's called a microburst. So it's the beginning of a thunder head formation about 90 seconds of a thunder head.
You have the vertical winds at like 50, 60, 70 miles an hour vertically in the middle of the microburst on the sides of the microburst, same thing goes down. Those are some of the most extreme weather events that are hard for the drones to handle. What are they doing those circumstances? Do they turn around and leave or they land immediately or what's their protocol?
So it really depends on big of this. This is actually one of the first things we developed AI to forecast. It's because if this is really big, right, if it's kilometers across and really strong, then we can't, you know, if we're in it, we're going to parachute landing. And so we know this because in a lot of our operations around the world, we're doing emergency deliveries for, you know, patient on the table delivering blood situations, we will take, we will basically ignore our weather limits and fly in very extreme weather.
So we go through these things, but then for non emergency deliveries, we rely on our forecasts and keep us out of this stuff in those really extreme events. If they're small enough, yeah, the control system will find its way through it. But of course, you know, the aircraft has its physics limits, right? It can only climb so fast, they can only do so much.
And so if the in certain situations, they can't overcome them, and yeah, that's when the parachute kicks in. I assume there's some sort of wind limit that there's just no chance for anything to fly through successfully. It's got to be around 100 miles per hour or so, maybe a little bit less. I don't know.
But there's certain storms where it's just like, you better just parachute out because there's no there, there's no success as a possibility, regardless of the size of this thing, like 30 seconds at 150 miles per hour is knocking down massive trees here. And so I'm assuming it's taken to drone off its course quite a bit. There's a certain mountain pass in Rwanda I'm very familiar with because we have to fly through this mountain pass to serve about a third of the country there. And in this mountain pass, it is winds get whipping like the winds can be higher than we fly.
We fly that aircraft at like, what is it? 60, 70 miles an hour and the winds get up to 100 miles an hour. And you'll see our drones flying backwards as it tries to fly through it, developing the control system and logic to like, because most of those winds are dusty, right? So if you can kind of hang, if you can stay in the air long enough and stay out and then punch through it at the right moment, you can get to the mountain pass.
Yeah, it was a big breakthrough. We figured out how to make that logic robust so that you see the drones just flying backwards for a while, flying backwards for a while, flying backwards for a while, and then Florida at the right second, it's estimating the winds dying down online and then it punches through the mountain pass and gets through. Do you have any video feeds? Because you're going to come with some great drama in those moments.
If you capture video, just when it's really gnarly, you know, I got a great video of the logs of that. You can see the position on the math going backwards and things. I think Hollywood's going to call you for the log file. Let's talk more about that wing.
So did you guys just put the wing on there? Because you knew eventually we're going to use it. And so you just had it in manufacturing for a long time but couldn't use it? Yeah, absolutely.
We knew we needed the range. You get about 10x more range flying on a wing for the same energy than hovering. And we need our customers need that range. So many of our use cases need that range.
And so, yeah, we always knew we needed the range of flying on a wing. And we decided to launch without having developed that system yet. Really just how we're wired. We want to get out into the real world fast because we just know when you're in the real world serving customers, you're going to learn a lot of things you just can't learn any other way.
And so we want to get out there earlier. Yeah, and that hardware was there and the teams that spent all this time developing that hardware were like, we want to see a fly on the wing. And of course, we've been doing the other test sites for a long time as we've been developing that capability. It is one of those things where you kind of develop it and then wait.
And then once you get to once you can, yeah, I think one of the things you know, you're talking about regulations and safety like that is also part of a really difficult thing in a startup is we hire people who like inherent urgency because if you set a deadline on safety, you can end up in a really bad situation. Right? If you're like, cool, we must ship this on this date. Some of the concerns you hear about of AV companies that are hurt people in the past, is that they take that mindset and they try to and they'll fool themselves and think they're ready.
As opposed to saying, no, no, we set a safety bar and we decide how we measure ourselves against that safety bar. And that's when we ship. It means your dates aren't quite as predictable. And so if you still need to move fast and see people with a very inherent sense of urgency to work through those problems and get there as opposed to like more traditional like, you know, we have a date and we're going for management approach.
So what was the range prior to the wing and then of a typical drone, like I assume good conditions, like how far did they go and how long a time and then you said 10x so I can do the math. Yeah, that's a huge one. Yeah, great. Yeah.
So we're doing about a mile and a half hovering and we'll be able to do right now we're about five miles on the wing and we'll be able to take that about 10 miles over time. So again, as we continue to validate and work our way up to it once we feel confident. And I assume each drone launches from a location and then has to return to the same location, at least until you get multiple hubs in a city or something. Yeah, that's actually that's a software feature that's coming in released next year is that ability to go from one dock, go make a delivery and then dock somewhere else.
But yeah, you do exactly right. We don't have the density of docking locations yet to be that right. So that cuts your range in half because you have to get out there and you got to get back. Exactly.
Okay. So you say five miles is that if I live five miles from your facility, do I get delivery? So I got to be two and a half miles. No, if we can live five miles.
Yeah. So once we have that, that we call, we can talk in a different location nearby the delivery site. Yeah, we can do more than 10 miles. Right.
That's actually the thing I we've learned over the years. It's way better when you're working with these partners to talk about a conservative range than like where you're going to go in the future. Because it's just it's so complicated to talk about that when you get into the details of your terrain and your physics and your and your local weather and all that stuff. It's like, no, no, we just talk about this little circle and then they're thrilled and we can do more than that.
Right. I was just flying my drone the other day. I have a little DJI flip and I was flying it too far away, like slightly too far away to where it was telling me to come back and I'm like, yeah, I'm coming back. So I start flying it back and then the wind picks up going against it on the way back and I'm sitting there thinking like, oh man, it's just not going to make it back.
You know, because the battery percentage continues to go down and it's still 1200 meters away and it's very dramatic. It did make it back to the house, thankfully, which is fairly, I got to imagine that's a stressful, you know, a range anxiety with our new EVs. I'm sure you probably have extreme forms of range anxiety with your because these are expensive machines, right? What does, you know, what's an all in cost on one if you can share that to develop a manufacturer?
What are we talking about? I can't show that specifically, but it's lower than you would think. And this kind of, this is one of the reasons we develop our own drones, both for this range problem we're talking about and for the cost, but the for the range, like, you take our fixed wing platforms, this is what we do with these very long range deliveries with no hover capability just flies like a plane. We advertise basically a 50 mile service radius, but like on it, it wasn't windy and there wasn't a mountain in the way.
It could easily do 100 mile service radius. So you literally have twice as much energy as you would need nominally so that we can make it back in those windy days reliably. And that's just really important because once you start serving a hospital, delivering blood, you can't be like, oh, it's too windy today. Sorry, guys, we don't serve you.
We only reach the people closer. It's like, no, we turn you on and we want to serve you all the time. Yeah. Does anybody get underwhelmed by the range?
When you say five miles? I'm not, I'm not from stones here. I'm just saying like, I know you're innovating, but does anyone ever go like, I can't seem small. It all just depends on the use case, right?
Like this is like that, the 10 miles was developed going really deep with our health partners and exactly on all the use cases that they want to use the drones in metro areas. And of course, when you go out of metrics, that's where the 50 mile range drone comes in handy. And all of this has been developed just, you know, basically technology second customer first. So deep with the customers, you know, we even have, like for this, a precision delivery platform, we had contracts with partners, you know, in the, while we were still in what we would call like the conceptual phase of that project, right?
Nothing was locked in yet. And having those contracts with the partners gets them to give you like, that gets them invested enough in us to give us the feedback and the data to make sure that we make something that's useful for them. And so yeah, some people get overwhelmed, but we just have that confidence. We've done so much time in these use cases, analyzing them, going deep with our partners to just have confidence we're making a platform that'll serve their use case as well.
Well friends, I'm here with my good friend Chris Kelly over at Oggman code. Chris, I'm a fan. I use Augie on the daily. It's one of my daily drivers.
I use cloud code. I use Oggman's Augie. And I also use Antcode and others, but Augie, I keep going back to it. And here's where I'm at.
I feel like not enough of our audience knows about Augment code, not enough about Augie, the CLI. It's amazing. I love it. What can you share?
Yeah, we often say Augment is the best coding assistant you've never heard of. And that's both frustrating as some of that works there. And it's like very proud of the work we've done, but also like inspiring like we want to go and sort of punch above our weight because like we aren't anthropic and we aren't open AI. And so the quality of the product itself, you know, with our context engine, once you do touch it, people are like just blown away by that.
And so like that keeps you going every day. So not the present lead here, but this is a paid spot. You are sponsoring this show to get this awareness. Now at the same time, we're selective.
And I love to use your tool. But there is in the world. So a lot of developers look at the space and say, okay, well, how long can this work? How long is this sustainable in the case of cursor or Windsor?
Or you pick the name and you think this kind of tokens help me shape a lens for audience? I think it's a lot of awareness, right? Like, um, cursor got a lot of, um, publicity early on for like fast revenue growth, which well deserved, I think, you know, frankly, some of the media got that gets the story wrong and that like, if I gave you a dollar 50 for every dollar you sent me, I'd be the fastest growing startup in the, in the valley. And so when you're selling discounted tokens, yes, of course you're going to go very fast.
But all that money plus more goes to the model providers. So I think the real story is the story of entropic and, you know, being an API provider, I think the market just moves so fast. And there's so many pieces of competition out there that it's just hard to get noticed. So friends, I love augment code and I love using Augie and I highly recommend you use it.
I love using Augie. I can hand Augie a well-defined specification, a well-defined PEP as I call them in my world and agent flow and it executes falsely. So the cool thing about Augie that I love most really is that context engine and I can hand it a task and I can churn away on my well-defined plan and just never bother me and accomplish the mission. It is so cool leveraging the latest models, the context engine and all the fun things behind the scenes in that awesome CLI.
So yes, go try it out, augmentcode.com. Right in the top there is a CLI icon, a terminal icon. Click that, install it and change the world. It's going to be awesome.
Augmentcode.com. And also by friends at Framer, you know, most design tools, they lock you behind a paywall. Well, Framer flips that script is a free full feature design tool that does something most site builders cannot. It's actually designed for designers.
Framer has already built the fastest way to publish beautiful production-ready websites but with design pages they defined and redefined what it means to design for the web. This isn't a webflow clone or a WordPress competitor, it is a true design platform, vectors, 3D transforms, gradients, wireframes, all the tools you actually use and they're all free. Unlimited projects, unlimited pages, unlimited collaborators and here's the kicker, you design, you iterate and publish all in one place. There's no figment handoff, there's no messy HTML import, there's no tool switching.
So if you're redesign and publish in one tool, start creating for free at framer.com slash design and use the promo code CHANGELOG for a free month of Framer Pro. Once again, framer.com slash design. Could you walk us through these or experience that either exists now or will be existing as you guys roll out domestically in the United States? From the end user perspective, but then also as we go maybe explain the software systems that have to support that because I'm fascinated where software meets the real world and there are all sorts of weird situations that you have to account for.
I know there's an app, I assume it's similar to a door dash kind of a thing where I'm going to order, let's just say I'm going to get a Chipotle burrito because I already cracked that earlier and I'm a fan, not a sponsor, I'm a fan of the old Chipotle burrito and I know it's under eight pounds so it's going to fit into my zip. Unless I get the double, I don't know, can you get a 10 pound burrito from Chipotle? Maybe not yet, someday, someday we can dream. I open up the zip line app, I assume, or do I open up the Chipotle app?
Maybe that's where we start. Do I start in the Chipotle app? Do I start in the zip line app or do I start? Yeah, so soon you'll be able to start in the Chipotle app.
Today you start in the zip line app and depending on where you live, if you live in the best place in the Dallas fourth area, you open that app and you're going to see a bunch of different storefronts. You'll see Walmart, Great Soon Walmart, Pharmacy, you'll see Blue Bell Ice Cream, Chipotle, you'll see a whole bunch of great restaurants, Buffalo Wings and others, and yeah, you pick what you want. That part of the experience feels a lot like DoorDash or someone driving the thing to you. Then they'll start prepping it.
Our partners will prep the food or prep the order. And then we put it in this thing that we call a zipping point, which is this fun little kiosk you put the package into and that'll, similar to how we deliver, the drone stays up high and the delivery zip comes down 100 meters, grabs the package out of the kiosk and brings it to you. And this is where things are very different than delivering my car. We actually have to warn people, hey, your food may be too hot to eat.
So we deliver so fast that we've had people be like, oh yeah, I just assume my hot wings would be soggy and they just stuck in their mouth and burnt their mouth because they're so used to how long it takes for deliveries to happen the old fashioned way that when it takes only a few minutes, it's well insulated and controlled the way we do it. The food's actually fresh and sometimes very hot still. Yeah, that's a great problem to have. So show me the Chipotle side from your integrators, your restaurants.
And I'm just picking on them because I know they're part of yours. Obviously, there's going to be a bunch of them. But imagine that I do order a Chipotle Reno out of zip. I assume an API call kicks off over to the Chipotle and makes the order and then they have to somehow tell the zip when it's ready.
Like how do they do that? Yeah, so they do they inter with Chipotle, they use their software system the way they use it for any order, right? If you order it over the counter or replace an order to Chipotle app and it shows up on their they call their make line. That's that's the people actually like put the thing put the order together.
So they're going to make this like any other food they're making. Our system gets hit over the API. So we know when they started that and we know when they're done. And then when they're done, you know, we'll put it in that kiosk.
Dispatch the zip, the drone over to come get it. You'll come pick it up. That's usually about a minute or two after it's ready. And then we deliver it a minute, you know, anywhere from one to five minutes later, depending on where you are, where you are, we deliver it in your yard.
And yeah, we have a fun little app that shows you the drone coming and gives you that really super precise ETA. I think one of the things I didn't appreciate about this kind of delivery that's really cool is like, I just how human centered it is, right? Like it's as opposed to like whenever that driver's going to show up and sometimes it's like, wait, why did they take that crazy route that's great? You know, if my kids are hungry, we tell you like, no, no, within a minute of when we're going to get actually show up and you can walk outside and pick it up, you know, this is there.
Now, can you hold your hand out and it'll put it in your hand? Don't recommend this. That can be a cool feature there. Come on, put your hand out.
You know, we'll put you have a third little, so you have like the big zip and the little zip and then like a hand that comes down, you know, just drops a little bit lower. Yeah, this is, you know, the key is like, I really, the way we talk about this is we don't want people to do stuff like that, but we test in case people do that kind of thing. So I delivered it in my arms and I love it. It felt good in it.
It felt very special. Do you like pause the delivery then when you detect like anomalies you don't want to be present in? I assume it's probably a phrase or terminology. Like a child standing there underneath your target.
Yeah, it's actually kind of funny that originally we thought we so we do a little bit of avoidance. So like if we're coming down and we see that person standing right there, we'll scoot over and then deliver next to them. They keep scooting closer, he keeps getting further. Exactly.
Like you can make a really fun game for kids that we don't want to be a fun game. You know what I mean? Yeah. Like we don't want to make this be a game of like, oh, it turns out if you chase this thing, it'll be a kind of game and then everybody wants to chase these things and we can't deliver.
And so basically what we found to work really well is just slow down. One of the things we like about that little delivery zip is it's very benign, right? If someone touches it or something, it's not a safety concern. And so yeah, we just slow down and keep going and make that delivery and get out of there.
Basically, the way I think it talk about is like we'd be boring. So that we're not creating a fun game for every kid. As a parent of young kids, I know he's like, I've brought him the test like to it. I can see I know exactly what if you did that avoidance with my three year old, she would have so much fun and we would never make deliveries.
Right. Well, my consideration for down the road of getting even more human centric is like allow the order to set like a mode like don't have fun with it. I just want my food because not that you always I know you guys want to save energy and battery and all that but like you're already pretty happy to have your food delivered from the sky. Like I can imagine like that's a moment already, but like to have a little bit of a personality with the thing I might take it over the top to where it's like, it's the only way we're ever going to get food is to just give us, you know, that's why I think the handoff would be actually amazing but yeah, too dangerous perhaps to for today.
Well, we'll say I love that idea. And your head is exactly where my head is and it's to me, it's not a question of if it's a question of when. So I look forward to it. Well, someone will always mess around to in those scenarios.
But did you mention it all when time of day you can't deliver? Is there like danger zones where you can't deliver in the evening or after dusk or is there like concerns you have lights on these things? Yeah, we can deliver anytime. Yeah, we deliver time 24 seven.
Yep. Yeah. Wow. Right now that's just limited by our partner hours and most of places we operate in the world, we deliver 24 seven with the health systems and then depending like it's always interesting to see like the work with restaurant partner and all of a sudden they'll realize just how much volume we're adding to their normal business and they're kind of like, Oh, wait a minute, like we operate with you all like and you can go 24 seven.
You're already operating 24 seven for other people. So we could do be open at night and there's a huge part of our economy that works at night, right? Night shift workers and things like that. There's, there's, well, we know that because all the health people we work with, they work 24 hours a day, but obviously lots of manufacturing operates 24 hours a day and a lot of our partners are seeing like, wow, there's a whole part of commerce they can make and they can address and a big part of the demand they can address by operating more hours and obviously partnering with us, we can do that in a way that's people really like.
And so yeah, it's really cool. I get whatever you need 24 hours a day. You know, I'm parent like just simple things, right? Like kid with spiking with a fever at night and you've ran out of the medication right to bring that fever down, right?
Like drag the only thing worse than having a kid with a fever is taking your kid to like a 24 hour pharmacy and I to go grab that stuff. You don't have. Yeah, Croupe is a big deal for, for parents. I know that we've battled, you know, several late night ER visits for Croupe and generally, you know, I don't want to go into like the medical scenario here, but like basically you have to be seen by some sort of medical professional to get a special medicine that is for Croupe that sort of helps your vocal cords and things, you know, reduce or whatever.
And it's kind of a pain in the butt because you kind of know, as a parent, you're like, you know what? I'm Dr. Momrom, Dr. I'm Dr.
Dad. Okay, I know I've been down this road before with my child. I just need that pretty that particular prescription. So if you have a relationship where you can do telehealth, which is super popular, you know, we would not have to leave the house at all if if that were a scenario, we can make a phone call and tell health and, you know, maybe 10 or 15 minutes later, we've got a delivered from zip.
It says, Hey, here's your group medicine. You have to leave the house. You can do it efficiently. You have to be on the road.
So I mean, like you talk about the efficiencies and environmental effects, like we have to drive, we have to lose sleep and maybe ruin our day the next day more. So we got the medicine and there's so many, you know, unintended consequences in that scenario that just make it so interesting to think about how you can reorient the world around this being a thing. Totally. I mean, I'm so excited about this.
And we have, we have, we have partnerships now with you about a dozen regional US health systems. And all of them have this use case in that partnership. They have some other ones as well, but this is they call it the physical side of telehealth. It's yeah, telehealth is obviously becoming a really, you know, predominant thing here.
And like you said, for so many things, like there's a physical side too. And so if you can get that inhaler delivered right away or that, that crew medication delivered right away, it's huge for the family. It's huge for, and you're touching on something too that I didn't appreciate when starting the plan. Now I appreciate a lot.
It's just how much health affects basically economy, right? Like you mentioned, like just, yeah, the parents not being exhausted the next day, they're going to do, you know, their work is going to be better. And like, and they're going to be more productive in the economy and just keeping people healthy in that sort of preventative way is something that I've become extremely passionate about because I've just seen this like cause and effect in my own life and all the patients we serve around the world. Just how powerful that is when, you know, a parent doesn't have to stay home or a parent doesn't have to, you know, basically be affected in their professional world by what could be a very preventable sort of health.
You know, some of these things kind of feel like inconveniences even, right? But obviously very cute, big life-threatening, but like a lot of this stuff, it's just a little bit of convenience just goes a long way for people staying healthy and productive. Have you, I imagine you probably have, where zip is at scale, where zip lines at scale and you don't have a couple hundred in in production, you have, I don't know, half a million, I don't know, a lot, just an astronomical number that you don't even consider today, how the world changes, maybe even how we see the world cause like, I can't imagine having it imagine or experienced a zip line delivering something to me. I'm sure it'll be cool once I have it in my own life.
But once this kind of technology, whether it's you or just generally like flights isn't only by only owned by United or Southwest, for example, you know, when this kind of delivery or scenario becomes ubiquitous, have you imagined that world and how that changes the world? Yeah, I mean, I'm super excited about it. This is part of the reason we spend so much time on things like making the system silent is, you know, one of the things we know is like, like, I don't want to notice these things, right? Like, you know, just like a bird flying over your house, how many birds flew over your house today?
You have no idea why? I don't hear them. And we want like, we spend a lot of time on things like that because we just know that like, as these things scale, there's certain things that we've learned from our experience that just matter a lot, like it being quiet. So there's certain things like that, they really, we spend a lot of time on to make sure that this is when the scales is, it's a world we actually want to live in.
And then of course, the net effects of this kind of instant delivery, I live in a small town here in California and yeah, like there's two bakeries, they're just like, they're so excited for when they get their little kiosk and they can just send out fresh bread in the morning to people. Yeah, I was just thinking about that. Timely deliveries. Exactly.
You know, and there's so many things on the personal life side like that, like getting fresh bread delivered. There's so many things on the works side, there's so many jobs that just require stuff, obviously doctors and medicines, it's so obvious and you know, auto mechanics, it's so obvious. Yesterday, just yesterday, my HVAC system in my house went out, a little blower had failed and the guy came out and he's like, I'll be back in two days with the part and it's like, no, no, you'll deliver the part right while he's there. And I looked it up the part he needed.
He was less than eight pounds. We can deliver it. Did you deliver it? No, we don't serve that area yet with HVAC part.
I know that it's so cool for like, hey, I got a solution for this. Hang on, there's no delay. I got the part. Yeah, even just talking to him about his business of like, you know, this is an independent guy who does a lot of these kind of HVAC repairs and you're fixing heaters and stuff.
And he said, his customers, they hate it when he charges for these visits just to figure out what he needs, right? Like, you know, he's just fixed it there on the spot, like not only would he be able to serve so many more customers, but this customer would be so much happier. And he has somebody who like hates that part of the customer, you know, conversation of like, I got to charge you for the 200 bucks for just to come see, come by and see this thing. He'd love that to go away because he hates that part of his job.
And anyway, there's so many pieces like that. I just can't wait to see what people imagine and how they will use it because every country we operate in, people are using it in ways I never expected. And I'll tell you one fun story from Dallas. So a couple this summer, we were looking at our usage data and most people would either order one address or to maybe two addresses.
But we saw this one person who was ordering to a different address almost every single day. What is this? What's going on here? And so we send this user an email saying, would you share like how you use in the service?
And so this is a postal delivery carrier and he his new resolution for this year was to eat healthier. And he was getting a salad delivered to him along his route every day for lunch. And I just like anyway, I just love that. I would have never have guessed.
I would have never have guessed. We call him the Johnny Appleseed of Zipline. You can see. What about gifting?
It's a great way to gift is like, just, hey, call somebody I've got side why? It's like, I got the delivery coming for you. And like this thing just drops gift out of the sky. Well, we did this.