Hey, welcome to React Around Them, the podcast where we keep you updated on all things React related. This show is sponsored by Reagan and produced by Top and Devs and Onvoid.
Top and Deves is very great.
Top and Deves we get top and pay and recognition or working on interesting problems and making meaningful community contributions an Void which provides remote design and software development services on the most client friendly business model, so clients only
pay after the tasks are delivered and approved. In today's episode, we will talk about flight flight Control and basically this is a tool that allows developers to not have to worry too much about the box when they deploy their applications. So it's going to be around the subject of developer operations.
My name is Lucas Pagani your a podcast.
Joining me in today's episode is also the host Chris Bruin.
Hello everybody, and we have a very special guest which is the CEO and co founder of flight Control, Brandom Buyer.
Excited to be here.
Thank you for being here, Brandom. Well let's just get into it. So Brandon, I'm sure you have explained this a million times already, but let's do it one more.
Can you pitch flight Control to the audience.
Please good thing never gets old. It's my baby. So flight Control is a platform as a service for deploying application, server, database, aesthetic sites to your own AWS account. Now why your own AWS account? Because it enables us to leap frog traditional platforms as a service on one most every metric. So, for example, you get two to six x faster built than any other platform, fifty to seventy five percent cheaper compute in near perfect reliability.
Awesome.
Okay, so let's bring it to something that might be a bit more popular in the eyes of front and developers, and then we can make a comparison.
To flight Control.
So to me at least, I know there are many platforms built on top of the AWS infrastructure and other big CLAWS, but I think Heroku might be one of the most famous and popular ones and it is known to be built on top of AWS. You can actually literally do a one on one mapping between the Heroku zones and the AWS zone. So if you want something to be in the same data center that you have deployed on AWS, you can just literally choose it.
And Heroko and it's going to be there. So how does flight control compare to HEROICU or is that not the kind of comparison that we should be making.
Yeah, that's definitely definitely the right comparison. Uh. And then the other you know, Heroica has been around a long time, so there might be actually new people that don't even know about it, but they probably know about versaill especially being you know, in the React space, so Vercell is
another you know comparison there. And you know, both of these platforms were created because infrastructure is really hard and developers want to be able to build applications quickly, ship them product production, and scale them to users all around the world. But if you're using abs directly, like you, it requires lots of specialized knowledge skills, time, like, it's just a pain in the butt. But these platforms like Heroca and Versail were created to make that so much easier,
and they are so much easier it's it's incredible. But the problem is that at some point you end up hitting problems and limitations. You had technical limitations where you know, maybe you need to customize some part of your infrastructure for security or something else and you just can't, or maybe you start getting charged a lot of money because Heroka and Ursell have very high markup over top of the aws cost. You know, so when you're just getting
started like who Care, you can run anywhere. But as you start scaling your app then it becomes, you know, a bigger question there. And I'll just share briefly an experience I had a while back. I think that helps illustrate this. So I was on a trip and as I entered my Airbnb, I was taken aback because almost every door cupboard in Appliance had a sticky note on it and either saying it was off limits or describing
the content. And it was it was painfully obvious that I was living in someone else's house, like they were dictating everything you can or cannot do this, And that approximates the experience of using a traditional platform of the service. You are living in someone else's house and you have strictly limited access, unable to go into the utility room for example, or make upgrades as you as your needs change.
But with flight Control, you fully own the house and you invite flight Control to come in and fully manage all the cleaning, painting, mowing the yard, even doing upgrades and renovations for you. And yes, you pay flight Control and modest fee for this service, but even after counting your mortgage payment, and your total cost is significantly less than the Airbnb or the Bursell markup with their ridiculous cleaning fees.
Okay, I like the analogy that this makes a lot of sense, But I guess my next question would be how do you balance having full access while also getting well also giving users a simpler facade into how to interact with it? Right? So, for example, when I initially went to flight Control's website, I initially made a connection between that and infrastructure as a code pools, so for example, pullooni or Terraform.
And I'm not sure if this is.
The right comparison that I should be making, but that's what I did at the time because I thought, Okay, it's going to simplify how I interact with AWS, but it's still going to give me control. So perhaps could we also make this comparison between Okay, like we sure can compare Heroku and ver Sell to fly Control, can we also compare flight control your Terraform and movie.
So the reason we created flight Control was we wanted the ease of use of our cell and Heroku, but the full control and the scalability of my own AWS account. And so before flag Control you had to choose between good developer experience or full control and scalability and no markup. You couldn't get both. But now a flag control you get the best of both the worlds because flag control provides that that super easy platform of the service developer experience.
It's just you know, click buttons whatever you want to do, super fast to set up, fully automated. But also it deploys to your own AWS account, So if you have the skills, then you can, you know, go into your AWS account, you can customize things to override and you don't have that markup.
But where does that configuration live?
Like in the sense of Terraform and Polumi, I can literally maintain the infrastructure with my versioning system. So if I'm using GID, I can just push commits and change my infrastructure with flight control, and where does that configuration would live?
So you get to choose two ways. You can store the configuration in flight control, so similar to Heroka oversell, where you're just clicking buttons and then I saved for you, or you can use infrastructure as code. And this is the infrastructure's code that we have designed that is a higher level abstraction than terraform or POLLUMI. And so our infrastructure's code is designed for developers. So instead of managing IP addresses and sub nets and networks in the infrastructure's code,
you're defining your services. I need, I need a database, I need a static site to find your built command, your start command. So it's it's literally the same configuration that you can do through the UI, you can also do it through code and store that in your your repository.
So we really give you the option. And so everything we do we try to give We try to make it super easy to adopt, but then also cover the complex use cases you know as your company scales, because that's the problem with traditional paths is you hit these scaling limits. And so that's where we're basically systematically removing those.
And how do you approach when the situations where users want to do something that goes beyond the abstractions that Flight Control has created or are this just not the case? Because AWS is a universe of things, right, it's gigantic. So if you were to provide uh, develop friendly abstraction in the form of infrastructure as a code for every single thing that exists on AWS. Then you would be maintaining a gigantic compilation of commands, right and maybe that
is what you did, but I'm not sure. And if that's not what you did, then what happens when a user wants to use something from AWS that the infrastructure as a code provided by flight Control doesn't have a connector yet?
Great question. So our goal is to take the BESTWS services, which are like I haven't done the math, but it's like a few percent of all DEVELOABLEWS services are like the core things that everyone is using so easy to cloud front Land, the rds and so these are the most common and so they're the long tale of AWS services that most people aren't going to need a go to use. So we're focusing on the most common use
cases and continually adding support for those. But the beauty of deploying to your AWS account is that you can do custom stuff alongside flight Control. So you can use flight Control for everything that it manages, and if you need to do something custom, well, you can do that however you want, and both things can live alongside each other really well. And so we see this, you know,
a scale larger companies. You know, some companies are their product is such that the infrastructure is like almost their product, Like it's very critical, it's a core part of their product.
But they also have a lot of other applications like their web application and in portals and things that are not core infrastructure, and so it's a waste of their time to manage the infrastructure for that, and so they use flight control for so they will manually manage their own product infrastructure and then everything else you use fly control for because it allows all the other developers to ship their stuff, you know, without taking time from the product infrastructure.
Gotcha interesting, very very interesting, very complex as well. So I appreciate you for creating this that that definitely saves up a ton of time for for us Mere Mortals. So, Peter, Chris, any questions thus far? Like, Chris, maybe do you have anything?
Yeah, just just a small thing, I guess because I'm looking at the site here and so you mentioned you can do kind of infrastructure as code. Is there a way can I even do you guys have like plug in via a code where like I have my Jason, you guys are using and I can I still get the visualization are there are they possible a guy through through the website.
So the we have Jason schema build into this right now where the Jason field has a Schema field and a lot of a lot of editors support that, and so you do get kind of the the in line hints as you're you're typing your Jason there. You don't get any of the guy showing up there. That is
something we could add. But whenever you create a project in a flight control you can you know, use the UI to can figure set up all your configuration and then you just mark that you want to start in your code and we give you the Jason for that. So that's it kind of covers that use case where you know you can easily see everything you can do with the UI and then just copy and paste the the or download the Jason file and you're good to go.
Yeah, very cool.
I'm with Lucas because if anyone's ever tried to deploy even something as soon simple as like a server, you think it's super easy. But even with tools like Columbia is like, hey, you need a gateway and you need rules and you need security.
Yes, you need like five to fifteen different AWS primitives put together in just the right way to run a simple server, and like there's so you know, five to fifteen different ways and you multiply all the ways this can be connected together or whatever, like there's so many ways to mess up on security, on whatnot, and so we just do that for you. You know, AWS is super awesome at the low level primitives, Like that's what they are world class at. They're not good at developer experience.
They're not good at the higher level layers, but they are absolutely world class at those low level building blocks.
And so it actually works out kind of nice because they can focus on the operational stuff, they're the reliability and then another company like US can come in and really like focus on the developer experience, which is this This split also enables it's a unique thing advantage that we have over the traditional platforms of the service because the traditional platforms are reinventing the wheel on every single thing because they are like literally have this custom layer
of custom software between you and AWS. But with US, we just use whatever AWS has ECS plus fargate or ECS plus e C two RDS for the database, et cetera. And so we can spend all our resources on the developer experience layer instead of reinventing the wheel on infrastructure.
Okay, so I am very eager to bring a different side of things, which is what about other cloud providers that maybe already provide a pretty decent developer experience. Talking specifically about Digital Ocean, it's not the hottest skin in the block, but I've always been amazed at how easy they make things. And they are their own provider, right, they have their own data centers, They're not relying on
infrastructure from other companies. Why don't just go with that instead of using AWS and trying to figure out what is the right abstraction layer, why not just go to a provider that it gives you access to the low level stuff and it's also very easy to set up everything.
Well. I have, so I personally have not like went down that road to Digital Ocean. I've done simple stuff. So I can't fully speak to that, but what I can say is that the market says the AWS is the winner. People keep coming back to AWS over and overuse because of its reliability, its longevity, it's it's uh, you know, price performance and the breadth of cloud native services.
So if you need to use if you want to use Lambda, you want to do service deployments, you're going to be on a w S. R d S is one of the best managed database services, and so like you're probably gonna want that. Also, you're gonna at some point work with other vendors that you're you know, you're maybe purchasing some kind of software or the service and
you want to self host it. It's going to be designed to run on a w S. It's it's kind of this network effect with a w S where you know, other other clouds are running on a w S also, and so the fastest way to access to them is you run on a w S in the same a w S data center. So there's just a long list of things like that that just push people towards a w S in the in their level of scale.
Uh.
I think digitaltion is fine, it's good, but you know, maybe we'll add support for that at some point.
Yeah, gotcham that.
With regards to adding support, how do you see support for the other three major players, Because I completely understand that Digital Ocean is at the bottom of the list in terms of like people actually using it on a large scale.
I like it very much.
But every time it's like I'm trying to convince people of hey, why don't you just start there, like you can migrate to to a big cloud afterwards, Like there's no need to start with that complexity migrate later.
Why not? Why would you start on somewhere that you're going to have to migrate.
Because I think that forces you to think about your infrastructure in a way that is independent of the cloud provider. If you already start by knowing that you're going to have to migrate clouds afterwards, then you're not gonna make choices that are too specific to one cloud. You're going to think of about serveralist functions, not with regards to aws LENDA, You're just going to think about servileist functions.
And that makes that forces the engineers to think about how to architect the system in a way that is
going to be easy to migrate to others afterwards. And even if you end up staying in just a WS for a very long time, just knowing that your infrastructure can be somewhat ned easily migrated because it's never really easy to migrate infrastructure, allows you to have a very good leverage in sales and it is known that the AWS consultants are going to give you a huge discount if you try to negotiate with them because they know that you have the power to migrate.
So that's basically why.
So yeah, here the last point is what the point I think you should start with. I think that is really the I think that's the only reason, in my opinion, that you would want to be able to migrate clouds is to negotiate deals like that, because you know, if you're just like theoretically doing building an application that to be portable, then you're also wasting a lot of time engineer brain cycles thinking about that and building that. Whereas, like you know, most companies are going to be totally
fine on NWS for a very long time. If you reach a point of scale at which it becomes a problem and you and you need to migrate to your own data center or something, you're going to have so much money and engineers like who cares at that point. But yeah, that's a good point.
Now that that that's also a good point. Yeah, in terms of just pushing things to the reality. It's it's hard to have startups that actually reach that level.
So it at a certain point it would be just easier to not worry about it and just choose one and stick to it.
Yeah, that that does make sense, and way I do think it's it's hard to choose one nowadays because there are some interesting choices popping up, not just speaking about abstractions on top of providers, but cloud.
Flare, for example.
It's a very good content contender that has come up, and there are particular points about cloud Flares services that I really like. So I wouldn't really say that I would migrate an entire application to cloud Flare or even build an entire application on cloud Flares infrastructure, because they don't support containers in any form.
They just have serverlusts and I haven't really bought one hundred percent serviles for all cases.
I think they're the right cases for it, and there are cases where it's just not the right choice. But for many other things, I would definitely go with cloud Flare. So I like having a hybrid approach to clouds and picking the parts of their services that best fit my needs and also their their pricing and et cetera.
But in any case, I think.
I got a bit sidetracked. But what I was going to say is you you mentioned, oh, perhaps we add support for digital otion later on. How do you see support for just Google Cloud and Asia for flight control?
I think that we will support that, probably GCP first and then ASURE later, but it's probably going to be a couple of years out. You know, maybe we never do. I don't know. I do know that the GCP is like has so many issues around shutting down services, poor
customer support. Like Railway is one of our competitors, for example, that is still mostly built on top of GCP, and they've had like these terrible stories where GCP or just like Rank revoke their quotas and all of a sudden, like stuff is failing and then they can't get in contact to support, and like you just don't have these kind of things with AWS and you know, so like
definitely there's some advantages there. And then Azure. I think the main reason I hear people going to Azure is because either they're doing dot net stuff or they got a really good deal on you know, discounts and whatnot. So you know, eventually we'll probably support for them. But the one thing we do is is really go deep on each provider that we support. So there's other competitors that are, like, right now, they support all the clouds,
but it's the least common denominator approach. For like, it's probably Kubernetes, and you can deploy the thing wherever, but you don't really get the best version of each cloud because you're just getting the lowest common denominator. And so we were intentional to say, hey, let's go deep on AWS. Let's take the things that AWS is really good good at and make those really easy to use.
Nice okay, And let's let's bring this closer to a developer actually wanting to use flight Control. What would be the situation we're talking about React developers here. So let's say that somebody's listening to this. They have started a React application and they just want to put it online, and they know that versall is an easy choice, netli fi is and is an easy choice when they hear AWS doesn't.
Sound easy, How does in practice.
Would look like for this developer to actually use flight Control to develop to deploy their application.
So it's it's going to be almost exactly the same as versell or netleth i. You sign up, you connect your GitHub account, you also connect your AWS account. So that's the unique thing and then you know, you just define your command start command, or it might even be automatically detected. And we have like presets for different frameworks that you can just click and it'll deploy it. So you can deploy static site or you can deploy server database.
So we really support the full breadth there. And but like why you know, if you're if you have a side project, you know, we have a free tier, but like you still have to pay for the a WS cost. The static sites are free, but if you pay, if it's a server, then there's still going to be a little bit of cost. So you're you're probably fine on on versell, but if you're building a real business, then why at WS becomes a really kind of important discussion. And reliability is one of the most one of the
most big important things. So for example, uh, just this week I was refreshing our my kind of industry stats and our railway, Fly and Versell have all had like almost twice a number of incidents in the past ninety days as a as a one prior, so to give you some numbers, Fly has had thirty nine incidents in the past ninety days and Vercell has had twenty four incidents in the past ninety days, but AWS has had on the services that we support is zero. So there's
just a huge difference on the reliability side. And this is because the traditional platforms have this whole custom layer of infrastructure that they have to manage and all their traffic is going through that, and so that that infrastructure has to support you know, millions and billions of request and it's really hard to build that level, you know,
scale of software. But when you deploy through AW through Flight Control, we set up your dedicated infrastructure and so it sets up a cloud front, sets up servers, and it's only your traffic going through that. There's no custom stuff that's serving billions of users. Besides, you know what AWS does on the back end, but it's nearly flawless.
Nice nice, Okay.
So that means that besides creating my AWS account, Like after the account is created, I would let's say that I only need the abstractions that Control provides, right, like I don't need anything custom, then I would only need to create my AWS account and then I can close AWS and never open it again.
Yes, if you need a uh some a WS billing stuff, then you can but we show you like the cost that you're paying AWS in our dashboard, we show you the logs. You know, we support the get pushed automated deployments, We support preview environments, so we support all the things that that you expect, you know, CP and memory charts and whatnot.
Nice. Okay, Okay, that that got me.
Yeah, So.
I think my question is based on, like, how does flag control our system like deploying les obuside next year's applications, because I think that's usually like a very big issue for most people on days like to really deploy SSR applications next year. So I don't do like is it something that has been experienced or it's something that we flight controlso finds you into address.
That's a spicy topic. So yes, we uh, many many people deployed next year as applications through flight Control, including ourselves. Our own application, our dashboard is next yea ass application with the app router. Unfortunately, it's one of the worst decisions I made in my career. We'd gotta be using remix.
But uh and and in fact, I literally just published a blog perst today on the flight Control blog called the Secret Knowledge to Self hosting next JAS, and the reality is that next JAS when deploying to a server, so okay, moving back up. Deploying to server is the only officially supported way to deploy next JS. Outside for sell, there is a project called open next that helps you deploy serverlessly, but it's not officially supported by next, so you have to do a bunch of hacks or the
open next to us. Also, deploying next to a server out of the box is not production ready unless you do not have a CDN. You only have one instance and you're not using image optimization. So for most people, there's a number of things that you have to do to be set your next GS application up to be
production ready. And the blog that I published today at fleccontrol dot dev covers all the things that you need to do to make that production ready, and those are things that you have to do even when you need a pla going through flight Control because it's it's next year specific and it's in your coat. So one of those, for example, is like hooking up and adding a custom
cash provider UH to rettus. Fle Control makes it easy to add the Rettus, but you still need to add that cash handler and your next chass can fig and so there's examples how to do that and whatnot. But so we do as much as we can, and the infrastructure that we that we set out fully supports that. We use cloud front for a CDN, which supports the stale WI revalidate header, which is important for next GS.
Cloud Flare does not support that for example, And so deploying if you're going to deploy next gas outside brocell fleck control is one of the best ways to do that because of the infrastructure we create. That's really good.
Actually, yeah, because I think that's usually been like a very big problem for so many days kind of like I know a lot of people like.
Like, oh, next I can't.
Deployed some the basis like a lot of people I know see next to those kind of vendor locked in like vendor like its kind of encourages this vendor lock to vessel kind of. So so most people that are building up people be like, oh, yeah, why don't we
just use vessel. So I think since you have like an alternative for that using flight contos also deployed that that would really be awful and I think maybe to it to drive people from that whole dilement of time to deploy it on the using whatever means they do.
Yeah, yes, yeah, we we often have people, you know, they hit the scaling limits on versail much much sooner than they think they hit the limits of the pro plan, and then they're paying one hundreds or thousands of dollars per month to versaill, which is ridiculous, and they'll switch the flight control and cut that, you know to a fraction. So it's maybe only twenty percent, maybe fifty percent. It kind of depends on you know, your unique set up there.
But you can save a ton of money by using your own aws because you get rid of all those markups.
Yeah, that's that's the one. Yeah, So look as you have any question, of course, I mean I could go on forever here. There's a lot of things, but I think that we were able to cover the most critical pieces. But Brendan, do tell me, is there anything that I haven't asked that you feel that is important enough that we should be talking about?
I think I think I'll just talk about the thing that we that were the latest thing we shipped and the next thing we're working on. So the latest thing we shipped is a new build system, which is two to six x faster than any other build system on any other provider, and so this is a huge difference. So for example, you know the cow dot com web that takes around a seventeen minutes to deploy in verse, and it only takes about three minutes on the new
Flight Control build system. And so if you have slow builds anywhere, like you might like fly Control because of this new build system. So we're super excited about that. And then the next big thing that we're going to be shipping is LAMB to support.
And so.
Right now Vercella is the only kind of managed platform that enables servilest next year as deployments, and so we're going to be adding support for Serverleist next year as deployments also, and then beyond that deploying LAMB as for any language, whether it's a web request or even triggers from like sqsques or databases or things like that, and
so that's going to be exciting as well. So we really think that Servilest versus servers is not a one size fits all solution, Like each one has its own strengths and weaknesses, and you need to build to use
both whenever the situation kind of requires it. And the problem is that a lot of these platforms only support one or the other, and so then you get a lot of this dogma and you know, propaganda about oh, like Servilis is the best or servers is the best, whatever, and it's just dumb because really you should have the ability on one single platform to choose from all the options and really do what works best for you.
Yes, I completely agree with this. I don't think that serviles is the future necessarily. I think that in a sense. Sure, like it's different from what we had in the past, but it's not for everyone. It's not for all cases, and I think people are missing the pointing there. So nice, awesome, awesome, Okay, let's do Let's start wrapping up and do a few rounds of promos as well. So Chris, why don't you start?
I I don't have much this week. I'll just point people to my blog, the criscrew dot I end. Actually yeah, I posted recently for one of my sass i rewrote I had a giant legacy dot net API, which I like dot net, but the way I grew the code base it became too much of a mess, and I just I rewrote the whole thing and go too much shorter, and it's it's so don't understand that the performance will go I think they're really doing magic behind the scenes, but it's way more performant than Yeah, it will be
easier to maintain. So it's the blog post is about that, not really the rewrite, but more of like philosophy and like I also state that you, you know, so clean at the very beginning, because you just mean yet.
Uh yeah, so.
I guess post a link if my computer can keep up with me.
Okay, your computer is definitely going kind of crazy, man, Like there were moments where your audio is like that.
I can't even reference it. But I do hope that this goes.
Live this way because it's way more funnier than just the regular audience. Yeah, and I had that with my my previous MacBook. It was Intel based and it would just go crazy doing during a few meetings. Yeah, I totally totally catch you, all right, man, So Peter, how about you?
Yeah, So I just wanted to not really more do, I just wanted to weference, like because I woulte on educative more like you put on web components with leads. So I just kind of experimented with leads recently, and since I think there's been a kind of OPA for this open web as okay, see and try to use the native web and web components for so much.
So I just said to just test with leads. So yeah, posted a link on ditch out. It's so yeah, I think that's just basically yeah, okay, cool.
I've been hearing a lot about it, so perhaps we should talk about this eventually. I will send both of your lengths in the comment section, So for those of you that are watching from YouTube or any other place that has a comment section, then you should probably be getting those links.
All right, So, Brendan, how about you?
Like We of course talked about like and show, but anything specifically you would like to promote.
Yeah, a couple of things. One is the Flight Control Engineering blog. It's mostly me writing on there, but I've gotten really good feedback on the article that I've been putting out around next jass type script type safety and things like this, so definitely definitely check that out. Fly
control dot deav slash blog. And then I'll also wanted to promote the idea of being a pilot and flying your own small plane something I've been obsessed with since I was a kid, And so if anyone is interested in talking about that, you can find me on on socials and chat it up.
Oh, so do you talk a bit about that?
Like you said, if anyone wants to know more about that, they should hit you up. But what can they expect from talking to you about this? Like were you able to accomplish this?
This go?
Like?
Are you officially a pilot? Are you in the middle of the process?
How does that I started my training when I was fifteen years old and got my license when I as soon as I turned seventeen, I was just a minimum age. So I've been been flying for a long time and it's an absolute blast. Like just if it makes you feel like a bird, just a level of freedom you can just I need to go to the airport and get on my plane and go fly anywhere I want the States.
That's so cool, Like, okay, that there are two there are two levels of of nice things about what you said. So the first one is being a pilot and being able to fly, and the second is you say I can just go to a to my plane.
And I don't think that everyone could purchase a plane.
But maybe there's another that's another myth, Like is that something that we can debunk quickly here, Like, yeah, how would it cost for someone to have a popular plane?
Almost everyone can learn to fly a plane. It's not hard. Uh, it only takes about forty hours of training, so it's not super expensive either. Also, you can own a plane. You can buy a plane. That's super than a car. So you know, I drove a junker car for a long time so that I can buy a plane. It's junk cars are totally fine. You don't need a forty thousand dollars car. You can get a forty thousand dollars plane or even cheaper than that.
So forty thousand dollars I can get a semi decent plane.
Yeah, you can like pointy to in the twenty starting at like twenty thousand. That's probably where the planes start. But you can also do shares, so you you know, buy a plane with a few other people. That is also common. But if you don't have a plane, you can always rent and it's just on an hourly basis, and so that's really affordable and no commitment. You can just fly as much as you want on an hourly basis.
Interesting, Okay, okay, what is the regular hourly basis to rent a plane?
It's I'm going to say one hundred and fifty dollars an hour. It varies on location, but approximately that and that includes gas.
Okay, that's that's pretty fine. So that's a reasonable number. Yeah, okay.
Like the thing that scares me about just having a send me like a nice plane but not like a super top one, is that.
I mean, it's a plane you don't want to fall, you know, it's different than a car. It's like, oh, if it's not working one hundred, that's fine, Like I can even push it a bit. But if I have to push a plane, then I don't think I'm gonna be able to tell that story. So that that part.
They all planes, no matter you know, how much the costs are or what they are, require annual inspections or even more often, and so they go to this rigorous inspection process to make sure that they're actually airworthy. So that that's part of the deal. Secondly, if your engine quits, it just turns into a glider and you can just glide down and land on airport or a field or road or anything. It's no big deal. And so it's
also significantly significantly safer than driving in a car. You're more likely to die in a car driving to the airport than flying your plane.
Okay, still the idea that, ah, the engine would stop and I would just have to glide until I find land, it's a bit terrifying, but yeah, okay.
That's it's something you cover in training, you practice it, it becomes just normal, so it becomes a non event some so you definitely train for all the things that can happen. So it's it's a good it's a good fun process. On it involves your your mind. There's a lot of like regulations and navigation and things, so that's kind of and systems fun to learn. And then it's also skills the actual skill of flying. So it's a good kind of holistic activity.
That not.
Okay, all right, that that's very interesting, Like you definitely got me interested about that, And that explains the name of the company. So now knowing that the company is like control that that that makes a lot of sense. Okay, Well, on my end, I'm just going to promote the two companies that produce the show.
So Top and Downs if very interested in other shows, not just react related.
And Onvoid is U n v O I D dot com and the I'm actually the founder of onvoid, so that's why I also speak about it that much. And we created a business model that is very different from what other traditional software agencies provide.
We actually only charge clients after the tasks are delivered and approved, and that's just so.
Much more client friendly because every single company complains that when they hire outsource developers or our designers, they have to pay by the hour and they never know how much is it going to take, and if something takes longer than expected, sometimes there's the feeling that like, oh, that's actually because the professional that are hired maybe is not good enough. But then the company ends up having.
To pay for that. So it's just this really weird situation, you know.
And we fixed all those problems by bringing them to our side, so the problems to exist, it's just that we make it very client friendly and all the complexities
are leaned towards us. So we estimate the effort of tasks beforehand, and we present that to the client and we only start to work once they approved, so they already know beforehand how much each individual task is going to cost and we only get paid by our work after it's delivered and approved, So even after delivery, the client can still do quality assurance before they say that
the work is actually approved. So it's a really interesting and very client friendly business model, and it's so much that we are actually having to choose our clients because we can't really say yes to our companies just because of.
Human resources available. So it's a really good position to be in.
Well, so that's it if you're interested U n v O I D dot com BOYD. That's a thank you for sticking up until the end.
That was a really interesting episode and I will see you in the next one.