[0:00:00] S: Brandon, welcome to the show.

[0:00:02] B: Thank you. Good to be here.

[0:00:04] S: Yeah, thanks so much for being here. I think the last time I saw you was back in May in Miami, at the Infobip Shift Conference USA. Then I guess, are you heading to Infobip Shift in Croatia next month?

[0:00:17] B: Yes, I am. Are you?

[0:00:18] S: Awesome. Yes, I will be there. I guess, we'll cross paths again. Fantastic. We could have waited and did this in person.

[0:00:25] B: Yeah.

[0:00:27] S: Great. Well, let's introduce you to the audience. Let's start with some basics. Who are you? What do you do and how do you get to where you are today?

[0:00:35] B: All right. I am a CEO and Co-Founder of Flightcontrol. Previously, creator of Blitz.js. I'm a software engineer in my whole career. I love doing business stuff, creating businesses. Flightcontrol is the first real, significant business that I've got into, so that's fun. Outside of work, I like flying airplanes upside down and helicopters right side up.

[0:01:02] S: Yes. You're the only founder and engineer that I know of that owns their own plane, although I'm sure that that also flies it. I'm sure Marc Benioff owns a plane, but he probably doesn't fly it himself.

[0:01:15] B: Yeah.

[0:01:17] S: Was Flightcontrol a YC company? Is that right?

[0:01:19] B: Yes, it was. We went through Y Combinator, Winter 22, which are, yes, Winter 22, which was January to March the last year, beginning of 22.

[0:01:28] S: Fantastic. I want to talk a little bit about platform as a service and how that – what that means as a people deploying infrastructure to various services and also, how it compares to things like AWS and doing things more DIY. Maybe a good place to start is, what is platform as a service and how does it differ than just using something like AWS services directly?

[0:01:57] B: First, so platform as a service is a little bit of a wishy-washy definition. But typically, people think of it as Heroku railway render, these full abstractions over top of AWS. That's been the de facto standard for a lot of people, a company starting up and it's because it's really easy to deploy and stuff. What happened is more often than not, it's actually technical debt and you will have to eventually – you'll eventually outgrow the platform as a service, either because of cost, or limitations around control, or scalability, or maybe reliability. There's just so many things that can go wrong there.

It was the best of at least of two evils, because on the other hand, you have AWS, which is arguably the most powerful, the most scalable, the most secure. But it's so low level and you have to assemble five to 15 different low-level components together just to deploy a simple web upgrade. That's never good either.

My co-founder and I both were lie, just didn't like this trade off. We were like, “Why can't you have the good developer experience on the platform, but on my own AWS account, where you can get that real power and scalability?” That's really what we created Flightcontrol to do.

[0:03:23] S: Do you think things like the movement around infrastructure as code has helped with the management of AWS directly?

[0:03:32] B: Oh, absolutely. Infrastructure as code is just almost critical, because before infrastructure as code, what you would do is you would – how to click ops. You would go hunt and pack around the AWS console, change some settings, or whatever. Then, what happens if you need to recreate that environment in a different region, or whatever? You have no idea what settings you've changed and how to save them. Infrastructure as code gives you a concrete definition in your code base of what the infrastructure should be, and so it allows you to easily reproduce it.

But the problem is things like Terraform and CDK are a very low level also. You just have to know a lot of things. What we have done is created a higher level abstraction, which we typically refer to as flightcontrol.json. It's designed for developers. Our whole philosophy here is making developer first infrastructure. Giving the power of AWS to developers in an easy, flexible package.

[0:04:37] S: Yeah. You mentioned Heroku. I want to touch, go a little bit deeper on that. I can remember when Heroku launched back in, it was late 2000s. I think 2007 is the founding of Heroku. It was a magical experience, to be able to go and basically just get pushed, deploy. I think it was really one of the first cloud native development environments that existed. In comparison to essentially, going and spinning up EC2 instances on AWS and managing your deployment through Jenkins, or something like that and dealing with all those raw components on AWS. It was just like magical experience.

I think, you mentioned that when you're using things platforms as a service, people, as those companies scale, or as the infrastructure scales, they run into different challenges around just –it's basically technical debt. There's also cost issue with that. From your perspective, what were some of the challenges with Heroku? I mean, they ended up selling the Salesforce. I feel like, they've grown that business, but it's not really in the zeitgeist of the magical experience that it was 15 years ago. No one's really talking about, “Oh, did you see the latest thing that came out from Heroku right now versus 15 years ago?”

[0:05:56] B: Yeah. I think, they've failed to invest in keeping up the data. It doesn't support HTTP, too. Just some of this basic stuff. It's degraded a lot on that respect and reliability. They've had security issues. It is definitely sad. It's definitely such an iconic service. But that said, even as great as it was, a lot of companies, for example, Instacart started there, but then they outgrow it. In some cases, that can be a very expensive and time-consuming migration, until, depending on how invested they were there.

We're trying to prevent that. We're trying to have a platform that is really easy for startups, is just as easy as Heroku, or whatever. You don't have to be an AWS expert, but then it will theoretically scale with you forever, because it's using your own dedicated infrastructure on AWS. You have the access and control that you need to customize, or tweak stuff.

[0:06:55] S: What about from a security perspective? I mean, I think the advantage of the traditional platform of service, if they do security right, then it's like, is out of sight, out of mind in some capacity. Then if you're doing AWS correctly, you can have a very secure environment, but you can also have a S3 bucket that's wide open to the public. I think they only recently made it not the default setting. Then, I guess, how do these things compare and then also, compare to what you're doing at Flightcontrol?

[0:07:24] B: Yeah. With Heroku, they have a custom layer of infrastructure between you and AWS. There's more software. There's more opportunity for issues. But generally, generally they're good at it. On AWS, the nice thing is that we automate all of that. We give you the best-in-class setup that's already secure, that has everything you need. Of course, you could go in and mess something up yourself. But we're trying to provide education around that and just adding more and more features, so that, for example, making it easy to give your – the rest of your team access to your AWS account. That's something that we can add to make it easier.

Generally, you get a more secure setup by default, because it's your own private account. We deploy stuff to a VPC, virtual private network. There's a lot of companies that have compliance concerns for around, like government, healthcare and whatever, and they need that. If you use something like a database on AWS and your backend is deployed to Vercel, then you're actually connecting to that database over the open network and you're relying on those database credentials to keep you secure. But if you deploy everything within your AWS VPC, then that database can be private to the public. You can't even access it to try to brute force your way into it. That's a big benefit.

[0:08:59] S: Listen, yeah, and for any regulated industry, or a company that's on a certain scale that has a lot of customer information that they need to protect, that's going to be an absolute, like P zero priority for them, versus just essentially relying on the database credentials to keep things secure.

In terms of the deployment models, so with things like Heroku, Vercel, it's very simple to do, and basically, you can connect it to your Git account, or those other means as well. But essentially, you push to a branch. It's just going to deploy auto deploy it. Everything is taken care of you from a CICD standpoint. You can roll those things back. AWS, you're probably going to have to use, build and develop your own CICD pipeline using a tool. How does that compare to what you can do with Flightcontrol?

[0:09:57] B: We support both. We will automate all the CICD for you. Have the Git push deployments by default. We have preview environments for branches, so to create a branch. We have full stack preview environments. Not just the front-end, but also your backend, your database, your Redis, your private worker, all of that can be spun up by the temporary environment. Buffer customers who want more power features, if they want to control the build for some reason, and they can point us to their image registry. They would run the build, create the Docker image, upload it to the registry and then just send us a deploy hook, deploy trigger, and we'll just deploy that latest image for them.

[0:10:43] S: Then, maybe we can walk through, what is the process to getting started with Flightcontrol? I understand with some of these platforms as a service I'd use, things like Vercel, Heroku and so forth in the past, the startup process is pretty simple. That's really the attractive part of this. If I'm a one, or two-person company that's just starting, I don't even have to think about that stuff. I can go focus on actually, trying to get customers, or build something that's going to be useful. Well, what is that real wrap-up period and what is the process to get started with Flightcontrol?

[0:11:13] B: It's exactly the same as you're used to with Heroku, or Vercel. Connect your AWS, or sorry, connect your GitHub account to find a few simple settings, like your build command, start command. For the most part, it'll be automatically detected. Then connect your AWS account and it's just off to the races.

It does take a little bit more time to get the initial infrastructure created, like 20, 25 minutes. Just because you're provisioning from scratch stuff in AWS, versus like a platform as a service, traditional is shared infrastructure. They can have servers warmed up, or ready to just swap in, for example. The initial setup is just a little bit longer with Flightcontrol, but then that pays off over time, including the power and flexibility you could.

[0:11:58] S: What are some of the challenges that this approach solves, versus using a platform as a service? I think it sounds like, you're matching the platform as a service from a developer tool standpoint in terms of ease of use, but what are some of the challenges, or limitations that traditional platforms as a service providers have that Flightcontrol is essentially addressing?

[0:12:22] B: The platforms as a service, they typically are marking up AWS costs, which we don't. They have more reliability issues, typically because of this extra software layer that they have between you and AWS. Typically, they have more limited regions. Whereas, AWS has many, many regions, I think almost 30 regions. Most of the platforms only give you a certain subset of that, sometimes only a one or two.

Then, if you need to customize some of the CDN settings, or some sort of the load balancer stuff, or the auto scaling rules, you’re limited to what they give you. In Flightcontrol’s case, if we don't support it, if we haven't built it yet, you still have it. It's in your account. You can go in there and customize something, even if we haven't made it easy, it's still possible.

[0:13:24] S: What are some of the initial customizations that infrastructure teams typically need to address as a – like, if they were using something like Heroku, they're going to hit, essentially, some limitation in the platform at some point. What is that first limitation that they're hitting that they would want to be able to customize?

[0:13:44] B: I think, depending on their level of traffic, auto scaling is probably one of them. I know a lot of Heroku customers end up using a third-party auto scaler connected to their accounts, as Heroku doesn't support what they need. That's something you have direct access with AWS. You can define based on TPU, or memory, or requests per second, sort of whatever makes sense for your setup. I think, the other thing is, is often just costs, especially Heroku. The others are, are a little bit more reasonable. Most of them, but Heroku has created the only costs.

[0:14:20] S: Then, in terms of the challenges that developers face when DIY with AWS. Because it’s really, they're like, “I'm not going to rely on Heroku. I'm not going to rely on Flightcontrol. I'm going to do this myself.” What are some of the big initial challenges that they come into? Is it mostly just the sheer complexity of essentially combining these 15 different services together to do something fairly simple, like launch a web application?

[0:14:50] B: Yeah, pretty much. If you've never done it before, you're in for a world of headache, and it just takes a long time to figure it out and get that working. It's just tons of iteration. You're literally, you will probably spend weeks, if not months, if you haven't done it before. If you have done it before, then you're inclined to like, “Oh, I can save some money. I can just roll it from scratch myself. But I don't have to worry about a third-party service.” Typically, that'll work for companies in their early stages.

What we typically see is as they bring more and more engineers on, eventually, the person who set that up is doing something else, or they're too busy. They can't manage it. Now, has to be more of a shared team, or someone else has to level up. It just becomes a lot more maintenance burden overhead to maintain that and to set it up for new and more services. We find that companies who started doing it themselves, when they get to around the series B stage, when they're really starting to scale the team, that's when they start, they're like, “Okay, this is not working anymore. We need a better developer experience. We need developers to have either access to spin up new services, either access for them to debug and monitor what's going on.”

[0:16:12] S: Yeah. It sounds like, if you're using platform as a service, it's great for side projects, small projects, maybe even building the initial prototypes for a business. Essentially, once you hit that series B phase, like you're mentioning, you're going to start to hit these challenges and you might have to do go through this painful migration. Then on the other extreme, you're managing everything from scratch. At AWS, you have to have either infrastructure team, or people, and your engineers that are very knowledgeable, or they have to learn those things as you’re going to slow down your, essentially, your build go-to market days. Then Flightcontrol is bridging those worlds in some capacity. Is that a fair description of the landscape?

[0:16:52] B: Yup. Yeah, for sure. We find that often, people will just be testing prototype stuff on a platform as a service. But when they're ready to go to production, they're like, “I want to use AWS,” because they know about the power and the scalability and the reliability of it. But they want something – they want that same experience. They want it to be easier.

[0:17:13] S: Yeah. How does this work for multiple regions? If I need to essentially be running infrastructure in Europe, maybe for compliance reasons with GDPR and I also have infrastructure running in the US, how do I manage those two regions, or how does Flightcontrol ease the management of those two different regions?

[0:17:35] B: A multi-region is a very complex and tough subject. What we support today, if you need to fully isolate your European infrastructure, then you would have two different environments. You would have a European environment and an environment for everyone else in the US, or whatever. Each of those, those could have their own database deployed there. They'd have their own specific URLs. That's a relatively straightforward. But if you want to have a single database that is multi-region and your app is running multiple regions with all the same data, that becomes much more difficult.

It's easy to deploy the infrastructure multiple places, but managing the data and keeping the data in all the places and up to sync is much more challenging. Hopefully, we can build something in the future that makes it easier for the larger company and start to aid that.

[0:18:34] S: We talked about the getting started process, the deployment model sounds like, it's relatively similar to using an existing platform as a service, except I'm just essentially, just going to spin out resources within my own AWS account. What about as I need to do certain customizations and configurations, what am I essentially interacting with at the Flightcontrol level in order to make sure that I'm using, I don’t’ know, RDS versus some other, like DynamoDB? Basically, how do I make these choices that are AWS specific and to customize it and how does that work with Flightcontrol?

[0:19:13] B: We have five main service types. You would come into Flightcontrol and you can add a server, a background worker, a RDS database, a Redis instance, or static site. Those are the five things that we support, which covers the vast majority of cases. We’ll be adding more over time, including serverless functions. That's the level that you think of like, “Okay, I need a server, I need a database.”

Then, inside of that, then we have the most common configuration that you're going to – the instance size, how many instances, how much do you want to – your auto scaling rules, your custom domain. Sometimes we expose a bit more custom stuff, like you can add a Datadog sidecar to your server, if you're doing a lot of monitoring and observability stuff. We started very simple, give you good defaults. Then slowly expose more and more configuration to you as you need it. Then, of course, ultimate is you go into AWS and you have unlimited access directly.

[0:20:17] S: Yeah. Then, if I go into AWS, I need to do these the customizations, essentially, is that tied, or back to what I'm doing at the Flightcontrol level? How are those two worlds connected if I do those customizations? How do I make sure that essentially, I can have that reproducibility for changes that happen and down the road?

[0:20:40] B: Good question. Depending on what you change, it may not be reproducible, but it will stay. We don't overwrite every configuration on every deploy. We just surgically update whatever needs to be updated. We're looking at various ways to ultimately, expose every possible configuration through Flightcontrol, or track the changes that you make in your account and then have a log of that that we can save, so that you can reproduce.

[0:21:11] S: In terms of the actual engineering of Flightcontrol itself, what are you – I'm assuming you're running at AWS, since you're essentially serving the AWS world, but what was the engineering process for building this? What is it actually built in? What sort of details can you share around the actual platform that you built?

[0:21:32] B: Sure. It's all full stack TypeScript. It’s NextJS front-end. NextJS and BlitzJS front-end. We're actually rebuilding the entire dashboard right now, using the new NextJS app directory and server components. This is a whole other discussion. But the most interesting part is the backend, which uses Temporal. Temporal.io, I believe it is. It's a workflow orchestration engine that was created at Uber. It's super powerful. It's definitely helped us build a much more robust system without it.

It was basically an abstraction over queues and crown jobs. It’s like, you can think about the J query days of building UI, where it's just, you're imperatively doing stuff all over. That's like using crown jobs. But Temporal is like React, where you just define what you want, and then it handles the retries and reliability and something like that for you.

[0:22:35] S: Yeah. Then, what are you using Temporal for? What is that helping you resource?

[0:22:41] B: That manages all the backend, all the deployments. It takes in the web hooks from GitHub and processes those, triggers deployments, manages environments, all of those sort of things, manages the builds.

[0:22:56] S: Then as a customer of Flightcontrol, am I running an instance of Flightcontrol within my own AWS, or is it more of a SaaS services, that's way that's connected to my AWS account and then manages AWS on my behalf?

[0:23:08] B: It's a fast service that's just connected to your AWS. The GitHub web hooks would come to our infrastructure, but then we issue commands to your account to run the bill, to run the deployments. All your infrastructure and all your environment variables, secrets, etc., are in your account. None of your user's traffic touches our stuff.

[0:23:31] S: Then, the company's been around now for what, you said 20, 22 was the YC bash that you went through.

[0:23:38] B: We really started building about two years ago.

[0:23:42] S: Okay. then What was the decision-making process? What led you to essentially doing full stack TypeScript? How did you make these different engineering choices? Have you regretted, or had to backtrack on any initial choices that you made?

[0:24:01] B: Choosing the same language, full stack, just had so many benefits, making it easier to move between different parts of the stack makes it easier to be a full stack engineer. It's also what I really had a lot of experience in. My Co-Founder, Mina, is CTO. He manages the engineering side, much more than I do. He had less experience with it, but still is fully gung-ho on type of languages and the benefits that brings you. I think the portals worked out really well. React and TypeScript, I think that all has worked out really well. I'm trying to think if there's anything that were regretted. I think if anything, maybe just some architectural stuff internally, but I think even most of that we got mostly right. It's impossible to get that perfect the first time.

[0:24:56] S: Yeah. I mean, you're probably doing something wrong, and you're probably moving too late if you're essentially, getting perfection from the beginning. Cause you're just not moving fast, especially as a young startup. You’re going to spend four years just whiteboarding things and getting the perfect architecture. Even that is probably not going to work. Then, I guess, when – in terms of the services that you're running on, are you using Kubernetes? What kind of infrastructure do you have set up to actually run Flightcontrol? Are you using Flightcontrol to run Flightcontrol?

[0:25:31] B: We are using Flightcontrol to run Flightcontrol. You mentioned Kubernetes. Our server service types are built on AWS Fargate. It's a similar thing to Kubernetes with a container orchestration engine, but it's a native AWS service. The Kubernetes is great, but it has a minimum cost of $200 to $300 per month, and it requires more expertise and knowledge of it to use it. We really like AWS Fargate, because starting price is $11 per month, so it's very, very affordable for companies to start with. It's relatively hands off, while still giving you a lot of the controls that you get with Kubernetes.

[0:26:17] S: You basically started this company during the era of the pandemic. I guess, what was some of the challenges you ran into, just like build – I'm assuming you're a mostly remote team. I believe, your co-founder is based in Toronto. Is that right? Yeah. You're in the United States. He's in Toronto. Your team is all over the place. Is that right?

[0:26:45] B: Yup.

[0:26:47] S: How did you think through that process of running a fully remote company? Have you been through that experience before, or was it something new?

[0:26:57] B: I mean, it was never even really a question about whether I would go remote or not. It was definitely remote, because that's what I wanted as an employee. I'd been working as a contractor remote. That's what I wanted. I'm building a company that I would actually want to work for. That's ultimately, my success for me is having a company that I love working at and that I would actually want to be an employee at, too.

My co-founder and I met online. We actually didn't meet in person until about six months after we incorporated initially. It was so funny. But it's worked out really well. We do try to get the team together in person, two to four times per year. Ideally two week-long retreats and then a couple other informal, maybe at a conference, or something like that. We're actually going to Quebec City next week for a week. That'll be awesome. The time before was Thailand and the time before that was Italy.

[0:28:07] S: Nice. Maybe I need to jump on the Flightcontrol bandwagon then. It sounds pretty great. Do you have to think about hiring differently when you're essentially establishing a fully remote company? Or, essentially the, I don't know, the traits of an individual that's successful in the environment different than the traits of an individual that maybe is more successful in a place where they're going into, like a place of business on a daily basis?

[0:28:32] B: There may be some subtle things there, but it's not something I think about when hiring someone. I can't think of anyone that I've been like, “Oh, they would be dead in office, but I remote, or vice versa.” I think, the main things that we look for is just a really high standard of excellence. Every part of their life, I think it's evident. Excellent people are just excellent at everything they do. They operate at a high level.

Even if it's not about the skills today, it's really about the level that you think about stuff, your curiosity, your hunger to learn, how fast do you learn? How are you thinking about the broader picture, how things fit together, the effects that something you may have down the road. But the big benefit of remote is that your pool of options is global, or nearly global, depending on time.

[0:29:32] S: Right. Yeah. Yeah, you're not limited by the talent pool that's within, I don't know, 50 miles in your office space, essentially.

[0:29:39] B: I really wish I could be in the office with my team. I think you would actually be more productive. Or actually, more effective maybe. But I can have the team that I have in office here in Dayton, Ohio. They're not going to move here. All things considered, I think it's much better being remote. Hopefully, at some point we'll be large enough where we can have offices in major cities, where people can come to, that live around there. If they want to, an optional hybrid thing. But I think we'll be primarily remote for the long haul.

[0:30:19] S: What’s the team structure today?

[0:30:23] B: I'm CEO. Co-founder is CTO. We have four engineers, three full-time. Wait, let me think of this up. Two full-time and a contractor and an intern. There's four reporting to Mina. Then, we have one developer relations. Senior Dev role, that's reporting to me. Most of the team is on engineering right now. Then I'm doing all the sales and marketing, and the go-to-market stuff. That have been a learning curve for sure. This is coming out of engineering and trying to learn sales and marketing and crushed.

[0:31:00] S: Yeah. I've been there myself. That's basically how I – I learned sales and marketing by being a founder, because I had to, because there's no one else to do it, basically, especially in the early days. Who was that first hire when you came out of the YC bash? Was it essentially scaling the engineering team?

[0:31:19] B: Actually, the very first hire we made was someone to help maintain BlitzJS. This was before we even started YC. It was just after we got our initial funding from angel investors. That's because I'd been spending most of my time on BlitzJS at that point, and so we needed someone else to take that over and maintain that, while, so I could focus on Flightcontrol. That worked out really well. Mina and I were just working together in Flightcontrol. It was right after YC that we brought on my brother as a junior engineer to help with the engineering stuff, and then hired a couple more, or at least another one a few months after that.

It's been slow hiring. You want to make sure that you don't hire too fast, because more people doesn't necessarily make you move faster. That adds a lot of overhead and also, expenses, cuts on your runway. Trying to grow as slowly as we can, but also, make sure that we don't cripple ourselves by not having enough help.

[0:32:27] S: Yes. Yeah. You mentioned BlitzJS. That's a open source front-end JavaScript framework that you started?

[0:32:36] B: The idea was to create a Ruby on Rails style developer experience for JavaScript and React. It had a lot of the same qualities, but never really reached that dream state. It just stayed as more like a toolkit to help you build full stack caps faster with NextJS. It got over 12,000 stars, has thousands of people around the world using it. Download is still growing slowly. That was really fun. That's how I learned that I have a good knack for developer experience. I really enjoyed building developer tools, marketing to developers. It really set me up to be successful here with Flightcontrol, because of that. It also was, gave me a good network and initial awareness. It’s how we got a lot of our first Flightcontrol customers.

[0:33:30] S: Yeah. How important, I guess, has that, essentially, contributing to open-source project and establishing it into your go-to market? It sounds like, it was instrumental in the landing some of those first customers. Is that a key part of your go-to market today?

[0:33:45] B: It's not a key part of our go-to market looking forward, but it has definitely been – I don't think we'd be where we are today without it, because it's just given so much awareness to us, to Flightcontrol, has given a lot of credibility. Cause a lot of people know about Blitz and they like the idea, even if they've never used it. And so, we got more mileage out of it than – just because the idea of it, people are like, “Oh, they like that.” Yeah, we still get traffic coming in from Flightcontrol for that. I think it'll be relatively smaller and smaller as we expand in other areas.

[0:34:24] S: I know you do a lot of public speaking. I guess, how critical has that been to growing this business and what is the motivation around that? How do you, I guess tie that to KPIs for the company?

[0:34:40] B: That’s a good question. We're still figuring out now what works, what's worth investing money and time in for growing Flightcontrol. It feels like, we haven't got a lot of value from either speaking in conferences, or sponsoring them. We haven't done a booth yet. We've done some of the smaller sponsorships, like [inaudible 0:35:04] something. If you're too focused on direct, like new customers from something, you can – it is tricky, because with a product like this, it's not just every day you switch hosting providers, or deployment tools.

You have to be top of mind, when an individual comes across that problem that they either need to deploy new service, or they need to improve the systems that they have. Part of it is just awareness and just being top of mind and reminding them, even if I'm just showing up at a conference and wearing my t-shirt, I can see recognition like, “Oh, yeah. The Flightcontrol.” That helps build your brand to a public conversation more, but it's really quite a long-term game.

[0:35:58] S: Yeah. I mean, I think from where you're establishing a new type of demployment system, essentially, or management of infrastructure system, then you have a big awareness challenge. That plays into, essentially, the timing, because not everybody's ready to switch infrastructure. Or, you mentioned someone might start out on Heroku, or Vercel, or one of the other platform providers. Then they hit series B and they're like, “Oh. Well, we need to re-platform at this point, or we need to think about making the switch.” It's like, are they aware that you’re available resource for at that time?

[0:36:39] B: Yup. You got to have the awareness. Next is familiarity that they actually understand what you do and your strengths and being able to picture how they would be able to use your product and how it would benefit them. Lastly, I think it's trust. Like, do they trust that you're reliable, that you're going to be around. All those things are things that we're working on.

[0:37:05] S: Then when you talk to engineers about what you're doing, is this something that they immediately see the value of, or is there essentially a pre-existing challenges that you see over and over again that you have to overcome?

[0:37:21] B: I think people see the value, the idea quite quickly. They're like, “Oh, yeah. That makes sense.” I think, the next stage of moving them from thinking about using something like Vercel, or render railway’s a default. That's a little bit more challenging, because AWS is a little bit more of a has a stigma. Like, oh, maybe worrying about like, are my cost going to balloon, or something? There's a little bit of mental barriers there that we have to work on with messaging stuff.

For the most part, people who are doing something serious, like running a real business, or whatever, they understand the value of AWS, and so, that becomes easier. It's more like the hobbyist inside of projects, where it's like, it's hard to get them, but we don't actually care about them that much, because they're not going to be paying us much money. We're free for individuals, so we like them. It's a good way to get awareness. We want to make it a good experience for them. But ultimately, they don't feel the business.

[0:38:30] S: What’s some of the switching costs for somebody who is migrating either from an existing platform, or maybe they were managing AWS themselves today, but they want to have, essentially, lower their internal resource costs to do that?

[0:38:43] B: It's usually pretty simple. As far as changing the application, is just deploy it and switch to DNS records. That's really all there is to it. Migrating a database is definitely more involved. We have some guides and are working on guides on that, especially for people migrating from Heroku, for example. But it's also something that we help customers with. We provide a lot of handling support for people who want to help migrating, or if they run into any weird AWS thing as they're using Flightcontrol, we're there to help them.

But even migrating databases is not that difficult. You basically put your app into a maintenance mode, or freeze it somehow, and then dump the database, upload it to the new database and connect your application, switch it to connect to the new database and then you're up and running. It usually doesn't take that long and you can do it. They're not off-peak time.

[0:39:39] S: What would you say is one of the biggest engineering challenges that you've faced over the last couple of years as your building those platform?

[0:39:48] B: This would be a better question for Mina, in that day-to-day, much more than I am. I mean, AWS itself is just crazy. The figuring out the APIs and each one is a little bit different. It has its own quirks.

[0:40:04] S: They even look different across regions as well.

[0:40:06] B: Yeah. Yeah. I'd take some time for Mina to really ramp up with. But now, I think he's pretty much – he thinks AWS and he can figure it out. What he says, it's like, some of these services and the APIs, it feels like, they got a team together in a room and they're like, how can we make this the most complicated, the most confusing API possible?

[0:40:31] S: Yeah. That probably just maybe speed to go-to market to get something out there. Yeah. In terms of like, you mentioned this hurdle around just getting a handle on the APIs and all the variability. As I mentioned, they can even vary in terms of what services are available across different regions. Sometimes they work a little bit different depending on the region. What about just like, how do you stay on top of the sheer number of services that are coming out from AWS at any given time? How do you prioritize your support for those different services?

[0:41:09] B: Well, frankly, half the stuff or more that they release is just junk. You throw or admit it.

[0:41:16] S: I mean, they have five different NoSQL databases available. How does the tiny possibly navigate that?

[0:41:24] B: Yeah. So much of the old, basic stuff. S3, EC2, load balancers, ECS. All of these are really, really good, reliable, they don't change. It can be challenging to figure it out and figure out the APIs. The nice thing is that once you've got to figure it out, it's extremely stable, reliable that hardly ever change stuff, or deprecate stuff. We're still just building out support for all the basic, the most commonly used, let alone the new shiny stuff. Frankly, most people just don't need all that stuff. There's going to be the some that are more sophisticated that will do it. Over time, we'll hopefully support more and more.

[0:42:09] S: Yeah. I mean, I think we get a little bit in one with the idea of these complicated infrastructure. It's the same thing in data engineering. You see this modern data stack that has 25 different services. Most people starting out there are data and pipeline, they need a spreadsheet, or maybe they need Redshift, or they need simple warehousing, simple reporting, and they don't need 30 components to do that. It's just over and it becomes an over engineering problem for different companies.

[0:42:41] B: Yeah. Unfortunately, engineers like to engineer, and sometimes at the detriment of the business.

[0:42:47] S: What's next for Flightcontrol? Is there anything exciting that you can share in terms of on the development front?

[0:42:55] B: Yeah. We're getting ready to roll out an entirely new marketing website. It has a whole new branding, look and feel. To accompany a new logo that we wrote out earlier this year. We have an entirely new dashboard that's built from the ground up with using NextJS and server components. All new design. All new UI/UX. We've been working with Overnice, a design agency out of Berlin. They did the branding and design for Prisma in the early days. They've been absolutely incredible together. Really awesome brand.

This new dashboard is going to – it's just going to function so much better. It has a ton of new features, like live AWS cost in the UI, so you can see exactly how much these services costing you. We have CPU and memory charts, a runtime logs. There's a bunch of new functionality in there. This should be rolling out within a month. Hopefully, we'll have that ready for early access for our current users just at the end of the August. But that's really exciting. Then after that, we're going to be working on a blazing-fast build service that should get a lot of builds under one minute.

[0:44:09] S: The dashboard that you mentioned, that's essentially a easier way to monitor, or not only costs, but essentially, what's going on on AWS?

[0:44:17] B: Yeah. I mean, that's the primary interface to Flightcontrol is the dashboard for creating projects and environment services managing them, monitoring them. Of course, we have the config us code, and the gap integrations and all of that. But that dashboard is your home.

[0:44:34] S: Awesome. Well, Brandon, thanks so much for being here. I'm looking forward to seeing you in person next month.

[0:44:41] B: Yeah, it'll be fun.

[0:44:42] S: Cheers.

[0:44:43] B: Cheers.

[END]