Flightcontrol with Brandon Bayer and Mina Abadir
Brandon Bayer and Mina Abadir introduce Flight Control, a deployment platform that brings Heroku-like simplicity to your own AWS account.
Episode Description
Brandon Bayer and Mina Abadir introduce Flight Control, a deployment platform that brings Heroku-like simplicity to your own AWS account.
Episode Summary
Brandon Bayer and Mina Abadir join the FSJam podcast to present Flight Control, their full-stack deployment platform that deploys applications to a user's own AWS account while providing the streamlined developer experience of platforms like Heroku. The conversation explores the core trade-off Flight Control addresses: traditional PaaS providers are easy but limiting, while AWS directly is powerful but overwhelmingly complex. The hosts walk through how the platform uses AWS Fargate for container orchestration, supports RDS databases, and automatically places a CloudFront CDN in front of web services. A practical segment has co-host Chris, who runs his SaaS on DigitalOcean with PM2, walk through what migrating to Flight Control would look like — connecting GitHub and AWS, pushing code, and letting the platform handle the rest. The discussion covers their infrastructure-as-code JSON config file and the upcoming visual UI layer being built on top of it, upcoming service types like static hosting, background workers, and Redis via ElastiCache, and the relationship between Flight Control and Blitz.js, which is pivoting to a framework-agnostic toolkit. The founders also share their origin story, thoughts on entrepreneurship, and plans for a public launch.
Chapters
00:00:00 - Introducing Flight Control
The episode opens with introductions before Brandon Bayer delivers the core pitch for Flight Control: a full-stack deployment platform that runs on the user's own AWS account, combining Heroku's ease of use with AWS's scalability, security, and extensibility. He explains the traditional trade-off developers face between simple-but-limited platforms and powerful-but-complex cloud infrastructure.
The hosts then discuss how Flight Control differs from front-end-focused platforms like Vercel and Netlify, which struggle with backend workloads. Brandon clarifies that Flight Control targets backend and full-stack deployments, managing both servers and databases. Anthony highlights that the platform provides full access to AWS resources through a clean interface, setting it apart from competitors that only handle one piece of the stack.
00:03:16 - Fargate, Containers, and Infrastructure Choices
Mina explains why Flight Control chose AWS Fargate as its compute layer, describing it as a middle ground between serverless functions and traditional EC2 instances — essentially Kubernetes without managing the cluster. Brandon adds that serverless Lambda and long-running containers each suit different use cases, and Flight Control plans to support both over time, starting with containers as the broadest common denominator.
Anthony draws parallels to the Redwood community's own journey through serverless pain points toward container-based deployments. The conversation turns to how Flight Control handles Docker, with Mina clarifying that users bring a standard Dockerfile rather than a Docker Compose setup, and Brandon explaining that Fargate itself serves as the orchestration layer, replacing Docker Compose's role of managing multi-service clusters.
00:07:21 - Infrastructure as Code and the Config File
Brandon outlines Flight Control's JSON-based infrastructure-as-code approach, designed to give app developers the benefits of tools like Terraform without the DevOps complexity. He discusses the tension between configuration files and visual UIs, revealing that the team is actively building a visual editor that stores config in a database and can optionally inject it into the user's repo, bridging both workflows.
Chris offers the developer's perspective, noting that UIs tend to surface all available options while config files can feel like guesswork. Brandon describes additional plans like opening pull requests from UI changes, showing how the two approaches can complement each other rather than compete. The discussion highlights how this design philosophy prioritizes accessibility for developers who lack DevOps expertise.
00:10:18 - A Practical Migration Walkthrough
Chris presents his own setup — a SaaS running on DigitalOcean with PM2 and Postgres — as a test case for Flight Control. Brandon walks through the migration flow: connect GitHub and AWS, push code, and Flight Control handles deployment, load balancing, DNS configuration, and everything else. The exchange covers domain setup, region selection, and how Flight Control's resources remain isolated from existing AWS infrastructure.
The conversation addresses practical concerns like cleanup and billing, with Brandon assuring that destroying a project removes all associated resources. Chris asks about coexisting with existing AWS setups, and Brandon explains the CloudFormation-based integration that securely links accounts with revocable access. This segment effectively demonstrates Flight Control's value proposition through a real-world scenario rather than abstract features.
00:13:07 - Upcoming Features and Service Types
Mina outlines several new service types in development: static site hosting via S3 with a CDN, background workers for long-running jobs, and an environment variable management UI. Brandon adds plans for an S3 bucket service type for file storage, Redis support through ElastiCache, and emphasizes that all public web services automatically get a CloudFront CDN — a feature he's surprised no competitor offers out of the box.
Brandon connects these service types back to the Redwood ecosystem, explaining how the combination would enable one-click production deployments for Redwood apps with separate API, static, and worker services all wired together. Anthony asks about inspiration from Serverless Framework, and Brandon dismisses it as too convoluted, while Anthony acknowledges the significant effort Redwood's team invested to achieve similar CDN functionality through that tool.
00:16:17 - Databases, AWS Transparency, and Developer Education
The discussion covers Flight Control's RDS database support and the team's own use of PlanetScale, before Brandon highlights a key differentiator: the dashboard provides direct links to corresponding AWS resources, helping users gradually become comfortable with AWS rather than hiding it entirely. This transparency also lets users tweak infrastructure beyond what Flight Control natively supports.
Chris raises the important topic of developer education, arguing that hosting providers should help users understand not just the tool but the broader context of deployment. Brandon references the book "Badass: Making Your Users Awesome" to frame their philosophy of helping developers level up rather than just documenting features. The conversation also touches on the challenge of understanding where framework responsibilities end and platform responsibilities begin.
00:24:15 - Founder Stories and Entrepreneurship
After Chris expresses interest in trying Flight Control, Brandon mentions their free white-glove migration assistance for early adopters. This sparks a broader conversation about doing things that don't scale, with Chris sharing his own experience as a founder learning to manually understand processes before automating them. Mina explains how this philosophy directly shapes their product development — they manually build each service type through the AWS console first.
Anthony asks Mina about his background, and he shares his journey from engineering to project management to running a DevOps consultancy, where he experienced firsthand how intimidating infrastructure is for small teams. He recounts reaching out to Brandon via DM the very day after Brandon decided to build Flight Control, discovering their visions were nearly identical. Brandon and Chris reflect on co-founder dynamics and the unique rewards and challenges of entrepreneurship.
00:29:54 - Blitz Toolkit, Public Launch, and Closing Thoughts
The final segment covers Flight Control's upcoming public launch on Product Hunt and Twitter, along with the Blitz.js pivot to a framework-agnostic open-source toolkit. Brandon explains that Blitz and Flight Control are distinct but complementary products forming a flywheel — Blitz helps developers build full-stack apps, while Flight Control helps them deploy. He details the easy migration path from current Blitz apps to the new toolkit, including automated codemods.
Brandon reveals that the Flight Control dashboard itself is built with Blitz.js, and shares plans for hiring later in the year. The hosts wrap up with contact information and social handles, with Anthony expressing his enthusiasm as an early adopter and promising future content about the platform. The episode closes at 00:37:23 with plans to reconvene for Flight Control's official public launch.
Transcript
00:00:00 - Anthony Campolo
Mina, how do you pronounce your last name?
00:00:03 - Mina Abadir
So it's Mina Abadeer.
00:00:04 - Anthony Campolo
You got that, Chris?
00:00:05 - Christopher Burns
Sorry, I'm the worst with pronunciations.
00:00:10 - Mina Abadir
No, that's fine. I totally get it.
00:00:11 - Christopher Burns
Mina Abadeer.
00:00:13 - Mina Abadir
Yeah, that's perfect.
00:00:14 - Christopher Burns
Okay. Welcome to the show, Brandon Bayer and Mina Abadeer. You two are the co-founders of something really, really exciting. Why don't you tell us a bit about it?
00:00:35 - Brandon Bayer
Flight Control is a full-stack deployment platform that runs on your own AWS account. You get the same developer experience as something like Heroku, but using your own AWS account.
Traditionally, you have to make the trade-off of something like Heroku that fully abstracts AWS, so it's really easy to use, but it has a bunch of limitations around scalability, security, and extensibility. So you either had to choose that, or if you went to AWS directly, then you get all the things of scalability and security and extensibility, but it's super hard to use, right? You have to have DevOps expertise.
We sort of take the best of both worlds and give you the least amount of problems of each side. You get the scalability and security of AWS, but the incredible ease of use of something like Heroku.
00:01:25 - Christopher Burns
As someone who has stayed away from most third-party big platforms like AWS, Google Cloud, Heroku, even someone who's literally just done Netlify and Vercel, what can you gain by going further but not actually taking the dip into things like Amazon?
00:01:43 - Brandon Bayer
Vercel and Netlify are really great, but they are targeted around front-end deployments. They really fall down whenever you go to do back-end stuff. Of course, they have serverless functions. You can do some back-end stuff, but it's mainly limited to simple things, and you quickly run into issues if you're running back end.
Prime example of this is that Vercel hosts their backend API not on Vercel. Vercel is targeted for front end, so we're not trying to compete with them for front end, but we are trying to provide the same developer experience as you get with Vercel, but for backend and then also full stack.
00:02:16 - Anthony Campolo
And it's important to mention that you are trying to own both the server and the database. Is that correct?
00:02:23 - Brandon Bayer
If you want us to, yeah. You can easily deploy an app with a database and connect them together, and we will manage all that for you.
00:02:31 - Anthony Campolo
Yes. I think that's an interesting point here because I've seen a lot of really great services recently that are the same pitch, you know, a backend Vercel, a backend Netlify, but they may just be owning the server part, or they may just be owning the database part. Like they're giving you a Postgres database or something like that. But you are giving full access to AWS resources with a nice UI on top.
And you've recently added RDS support and the core server is Fargate, so I'd be curious why you went with Fargate over any other way of running a service or server on AWS.
00:03:16 - Mina Abadir
Very nice service from AWS. It's basically Kubernetes without managing the cluster. It's somehow serverless, but for long-running containers you get a container running long term. It can scale up to a maximum that you can define, like you can say, okay, I need a maximum of two or three servers of this configuration of CPU and RAM, and it can scale with traffic. So if your traffic increases, Fargate will provision more servers for you.
This is a nice middle ground between serverless and full servers or bare metal servers, as we used to say for EC2. It's a middle ground which will work great and be perfect for, I would say, most applications.
00:03:58 - Brandon Bayer
The other thing to consider here is serverless Lambda functions versus container servers are not a one-size-fits-all solution. Some people's apps will work fine running on Lambda. Other people are better suited for long-running containers.
The problem is that a lot of services either do one or the other, and so if you need to switch, you have to totally switch providers. But where we're going is supporting both. So we're starting with containers since that's the most common denominator, or least common denominator, whatever it's supposed to be. It supports all the use cases, right?
Serverless works well for some cases but not others, but we do plan to add Lambda functions as well at some point.
00:04:33 - Anthony Campolo
Yeah, this is super interesting to me because I have been going through a similar journey that you both have from the Redwood side, because a lot of this I know has been built on work that has gone on with Blitz. It's been really exciting for us to see this company get built.
I remember, Brandon, this is your fourth time on the show, and I remember one of the times you were on, we had this whole roundtable episode. We were talking about, you know, how to deploy these FSJam kind of applications, and we were like, man, all the deployment options are just not that good. We really need to just make our own deployment platform.
Once we saw you announce it, we're like, oh, cool. We're doing the thing. We're going there. The problems came from trying to use this serverless technology and having these Lambdas and having all these problems that came along with Lambdas. And so with Redwood, we eventually got to the point where we were like, all right, let's just run this sucker on a server.
[00:05:27] And that was useful for people who were able to spin up VMs and work with PM2 and that kind of stuff. And that's where Chris has gone down that path. We started seeing things like Fly, and Fly was like, here's this container that you can just run and have a really nice container thing.
So I've found that the container seems to be a nice middle ground for a lot of people, more similar to an actual server, but it's still not like running a full VM, so it's got kind of a nicer DX associated with it.
I would be curious how much you integrate with, say, something like Docker Compose, because I know with Docker Compose you can just run a very simple, concise configuration-as-code type thing, and then it figures that out for you. But I also know Docker Compose is not exactly the same as just running a Dockerfile and has some specific things built into it. So if I had a Docker Compose file, could I bring that to Flight Control?
00:06:22 - Mina Abadir
So Docker Compose is mostly an orchestration layer on top of Docker. You orchestrate several Docker services. They all work together. You start all of them together and you tear them down all together.
We are a little bit different because we support single services. If you have your own Docker image, not specifically a Docker Compose setup that you need to run on a server, this is what we support out of the box. In our IaC file, you say, okay, I need to use this Dockerfile. Whenever we are building your project, we use the Dockerfile for you.
00:06:57 - Brandon Bayer
Docker Compose is almost like managing a cluster on a single machine. Our Docker Compose equivalent is Fargate, right? Fargate manages the cluster for you. You bring your Dockerfile, you just link your Dockerfile to Flight Control, and then we deploy that and handle it for you.
So we have the equivalent functionality of Docker Compose, but it's just our own configuration file that's somewhat similar.
00:07:21 - Anthony Campolo
Yeah. So let's get into that because you have a Flight Control JSON file. So you created your own infrastructure-as-code setup, essentially. Could you talk a little bit about how you decided the syntax for that, and then how you decided what to include and what kind of considerations around the DX went into creating something like that?
That's something that most services have, but not many developers will go through the process of creating something like that. It's kind of a specific thing. So I'd be curious how you even think about something like that.
00:07:52 - Brandon Bayer
Infrastructure as code is really, really great because you have this configuration that is in your code. You can easily parse, comment, and collaborate on it. You can copy and paste it across projects to easily spin up an entire set of servers and services and things.
But the problem is most infrastructure as code is designed for DevOps, Terraform, Pulumi, things like that. For a normal app developer that doesn't really know DevOps, it's basically way too complex. It's essentially out of the realm of possibility for you to do.
So what we're doing is bringing the benefits of infrastructure as code to app developers. Our configuration file is giving you the same benefits of the traditional infrastructure as code, but it's super easy to understand for app developers. We use higher-level abstractions, and so it's just really easy to configure things.
Some other providers have started with config and then later got rid of it in favor of UI. There's sort of this tension between using infrastructure as code versus configuring stuff through the user interface. There's a little bit more cognitive overhead to writing a JSON file, putting it into your repo versus point-and-click in the UI.
What we are in the process of right now, like literally this week, is trying to unify those things together because until now, the only way to configure Flight Control is through the config file. But this week we're adding a visual layer on top of it where we essentially store the config file in our database until at some point you can choose to inject that into your repo.
We're trying to give you the best of both worlds, where you can start with easy UI stuff, and then you can also inject to a config file and get those great infrastructure-as-code benefits.
00:09:28 - Christopher Burns
I think the biggest reason why I seem to like UIs more than config files is because UIs tend to show all the options. No matter how long the web page is, they're trying to explain all the options. In a config file, it doesn't do it because it's just TOML or YAML, and you feel like you're guessing your way through it to get to what you want.
Which way is better? I think there's definitely pros and cons to both ways, as we've spoken about, but I think it's all down to user preference. Having it stored in a database and then it can be injected, I think could be a really good way of saying, look, you want to customize it in a UI, but then you want it to be saved in a file. That's how you do it.
00:10:08 - Brandon Bayer
Yeah. And then the other thing we can do is, even if the file is stored in your repo, we can show it visually to you, right? And then you can change it in the UI. Then you click save and we open a PR to your repo for you.
00:10:18 - Christopher Burns
Let's try something a little bit different. I think this is interesting. I run my own SaaS product. It is not serverless. It is in our DigitalOcean droplet with a DigitalOcean Postgres database next to it.
00:10:32 - Anthony Campolo
You're a good potential customer.
00:10:34 - Christopher Burns
I know, I know. I use PM2 and I hate PM2 for managing my Redwood app and my Next app. How could I benefit from Flight Control?
00:10:44 - Brandon Bayer
Well, you can get rid of PM2, you can get rid of DigitalOcean, you can get rid of all the other manual stuff you're doing, and we'll just do it all for you.
00:10:53 - Christopher Burns
When you say you'll do it all for me, how does that look? Do I just push to Git and expect it to be deployed behind an IP address?
00:11:00 - Brandon Bayer
Yes, exactly. So you connect your GitHub account and your AWS account to Flight Control, and then git push, and we handle the rest.
00:11:07 - Christopher Burns
And what about things like Nginx? However you pronounce that, I've never said it out loud.
00:11:13 - Brandon Bayer
You don't need to think about that. We handle that. I think the load balancer is actually what handles that part, but you don't have to think about it or worry about that part.
00:11:21 - Christopher Burns
And what about my domains?
00:11:22 - Brandon Bayer
So you define your domain currently in our config file, and soon also in the UI. You define your domain, and then we will give you your DNS records, like a CNAME or whatever you need to set. As soon as you change those DNS settings, then traffic will automatically be routed to your Flight Control deployment.
00:11:38 - Christopher Burns
Interesting. Where is it all hosted? Are you hosting in America for me or am I hosting it myself? Who actually owns that cluster? Because as I understand, it's backed on AWS.
00:11:49 - Brandon Bayer
So you own it from your AWS account, but it can be in any AWS region. You define the region whenever you set up your project and we'll deploy it to that region. You own it wherever you want to own it.
00:12:02 - Christopher Burns
Awesome. And once I already have an AWS account that has loads of stuff already working on it, will Flight Control break it or will it just work all together?
00:12:10 - Brandon Bayer
Yeah, Flight Control will break it. Sorry. No, just kidding. Flight Control will not break it.
There's basically a one-click integration. We use a CloudFormation stack, which is what links our account with your account and gives us access into your account securely. You can revoke that at any time. The infrastructure that we create for you is isolated, so it's not going to mess with anything else.
If you're trying something out and you want to tear it down, then you can easily destroy that project or services from our dashboard and we'll remove all the resources for you.
00:12:40 - Christopher Burns
If I was to delete Flight Control on AWS, you would make sure that after the end of the month, there are no recurring payments? Because this is actually something that I've had myself. I've tried to delete everything off my AWS, and it's like, why is it still charging me? I've got nothing on here, and there's always stuff hiding in places.
00:12:58 - Brandon Bayer
Yeah, for sure. We delete everything that we create for you. So if you're getting charged, it's for something else that you did previously, not us. Unless we have a bug.
00:13:07 - Christopher Burns
What's the current plan today? What have you got today? Where's the future going? What big milestone features do you really want to implement that really excite you?
00:13:17 - Mina Abadir
Yeah, sure. Actually three main features, or four main features, that we're going to build. I'm not going to mention the Flight Control or the UI configuration that Brandon mentioned, because that's one thing that we're working on.
We're going to introduce three new service types. Static services: if you have a website that is just static files, HTML, images, CSS, JavaScript, no server-side component to it, you can easily build it, push it, and we host it on an S3 account for you with a CDN in front of it. We take all the pressure of starting a server or anything. We just build and push it for you, and it's available. It's really optimized, very fast. I was testing it yesterday and I was like, oh my God, yeah, that's nice. I'm going to use it myself.
The other thing is background workers. If you have long-running servers that are doing any background jobs, we're going to introduce a service type that is completely isolated. They don't have load balancers or CloudFront or anything in front of it, just servers running, doing background processing for you.
We're also going to introduce an environment variable UI component where you can edit and change your environment variables.
00:14:27 - Brandon Bayer
A few more service types are an S3 service type for just an easy way to create an S3 bucket for uploading and downloading files and easily linking that to your other services.
Also a service that will be backed using ElastiCache, which is a managed service provided by AWS, so you'll be able to easily add a Redis to your setup. I want to make sure to emphasize that all our public web services have a CloudFront CDN in front of them automatically. This is something no other hosting provider is doing. I can't believe that no one has done this yet. I can't believe we're the first one. But it's so obvious that you want a CDN in front of your web service, and you automatically get that with us.
You all are in the Redwood camp, so hopefully your wheels are turning now. With all these service types, you can see that we're going to be really awesome for hosting Redwood apps here very soon. Redwood, you have a separate API service and a separate static site service, and then potentially other workers or whatever. You'll be able to basically one-click deploy a production Redwood app with everything wired up for you.
00:15:30 - Anthony Campolo
Just recently, we had the team do a ton of work with the Serverless Framework to achieve something kind of similar. I'd be curious if you were looking at things like Serverless Framework for inspiration or if you're just like, figure this out ourselves.
00:15:46 - Brandon Bayer
Serverless Framework is way too convoluted to take inspiration from, in my opinion.
00:15:53 - Anthony Campolo
Well, yeah, that's why we had to wrap it with a kind of Redwood command, because it definitely took a ton of work to get going.
We've got it in a pretty good spot just for Redwood people, but I agree that it's kind of surprising that it's not an out-of-the-box solution, really. We had to do a ton of work to get that CDN where it is. So I definitely see a ton of value in that, and that was definitely a very smart choice.
00:16:17 - Christopher Burns
I don't know if I missed it, but what about databases? Are you helping host databases, or is that something that we should use a third-party service for?
00:16:25 - Brandon Bayer
So we support an RDS service type today. You can define your database service on Flight Control, and then we will automatically create and provision it. You can easily change your storage. You can set up storage auto-scaling, turn on delete protection, and so this is using RDS.
Personally, we're using PlanetScale because PlanetScale is awesome, but RDS is really great too, especially if you're not expecting huge scaling things for a long time. Then RDS is really nice to use.
I think something else that I should mention is that since you're using your AWS account, we're creating all these resources, right? But we also give you links out to those resources. In the Flight Control dashboard, you can click a View Logs button, a View Metrics button, and we link out to the corresponding AWS page. AWS is like a massive jungle, right? Like trying to figure out where you want to go. We give you direct links to all the places that you want to go.
[00:17:16] As you're using Flight Control, you start to become familiar with AWS and it becomes less and less intimidating. The other thing that's great with that is if there's a feature or a configuration that you need, but we don't support as a first-class thing yet, you can go into AWS and tweak our infrastructure that we create for you to do whatever you want to do, and it'll just work.
That's a real power that you get over something like Heroku that abstracts it all away and hides it from you.
00:17:43 - Christopher Burns
Why did you choose not to hide all the abstractions? Why did you choose to say, bring your own AWS account instead of we're going to abstract it away for you into our own accounting system? Is it so you can scale faster, as in you have to worry less about most things, or is it because you think that there's a lot of room to grow alongside AWS?
00:18:07 - Brandon Bayer
It is completely because of the user experience, the developer experience. Heroku is great, but inevitably every company who scales on Heroku reaches a point at which they outgrow Heroku. They reach the limits.
I've heard from at least one person that is interested in Flight Control that in their last company they started on Heroku, and they reached this point of scale where they had to migrate out to AWS, and they literally lost like $1 million in revenue opportunity from the long, expensive migration from Heroku to AWS.
Also, if you're on something that totally abstracts AWS, you can't securely connect to AWS services directly. In some cases you can do it over the internet. It's somewhat secure, but it's not like within a VPC where it's hyper-secure. And just in general, it's really hard to use AWS services from the second-layer providers.
A lot of these things you won't notice until a bit further down the road, but we're setting you up for success. That's a reason a lot of people don't start on Heroku these days, because they know of these scaling and security challenges.
00:19:09 - Christopher Burns
What would you say to people that really like the idea of Flight Control, but really hate giving Amazon money?
00:19:17 - Brandon Bayer
Well, there's not much I can say to that at this point other than that probably eventually we will support Google Cloud and Azure, but it's likely a few years out.
00:19:27 - Christopher Burns
I think it's different from choosing to buy local to choosing to buy from Amazon. But when it comes to computers and raw computational power, most things just use Amazon, even if you like it or not.
00:19:40 - Mina Abadir
Yeah, that's a good point. If you're using another provider, probably this provider is using AWS under the hood. So more or less, you're going to AWS.
00:19:50 - Christopher Burns
Someone's paying the bill.
00:19:51 - Mina Abadir
Right?
00:19:52 - Anthony Campolo
What kind of people have been signing up so far? What kind of projects have they been using? Do you see any patterns, or is it kind of all over the board in terms of what is being brought to Flight Control as early adopters?
00:20:05 - Brandon Bayer
It's fairly varied right now. We have a number of people who are just launching small apps and startups. We have one startup that's like a year or two old but has six million requests per month, and they migrated from Vercel to Flight Control.
Their monthly cost went from $2,000 a month to under $300 a month total, and that's because they're doing a lot of back-end IO processing, and Vercel is not designed for that. Like we talked about, it's for front end. We also have a little bit larger startups, and then also one agency that's using us right now is bringing on multiple accounts.
Our infrastructure as code is really powerful for agencies, especially since they're spinning up a lot of similar services. We've been working closely with them on designing that config file.
00:20:51 - Christopher Burns
One of my big questions is, how are you going to help with the teaching? Because actually, I think that's a lot of the bigger problem when it comes to hosting: answering the questions and getting them from, I want to host my app globally, I want it to be hosted in multiple countries, to, okay, my app is now hosted in many countries.
Does Netlify do that? Does Vercel? Does AWS by default? I guess they all do, but there's a lot of teaching and learning. This is actually something I did today: how do you allow your app to be seen under someone else's domain so they can access your app? It's a perfect example in SaaS apps, but how many people have actually written on the internet on how to do this? Vercel kind of allows it, but Vercel doesn't explain very well how to do it. It's like you kind of feel like you're just walking in the dark with your arms out, getting to the solution.
[00:21:42] And I found all these high-level things. Your hosting provider, whoever's helping you with this infrastructure, I think should be that wealth of knowledge to say, you need that; this is how to do that. I think that's really where we could see massive adoption in this area.
For example, AWS is great. You can do anything on AWS, but actually understanding AWS, you need a book just to understand AWS before you even get to a product in AWS and its acronyms.
00:22:09 - Brandon Bayer
Yeah, I think you have a really great point here. I'm actually currently reading the book, Badass: Making Your Users Awesome, I think is what it is. It talks about this whole thing of, a lot of times your marketing materials are all around, be a better developer, be a better photographer, but then as soon as you buy the product, like buy a camera, all of a sudden your user manual is all about the tool. Tweak this setting and tweak that, and you lose the overall context of being a better photographer, being a better developer.
It's talking about how you really want to help provide these paths and this training to your users to become the better developer or whatever that is that they are. There's a huge amount of stuff we can do here. This visual editor flow that we're working on this week is our first step in that direction. But yeah, 100% agree though. There's so much education stuff that we need to do.
00:22:55 - Christopher Burns
And I think the biggest thing that goes with that is the very gray mess of where something starts and where something ends. Like I said, this example, I was building it in Next.js middleware. I was adding in the middleware to detect domains and everything, but then Vercel is not Next.js. Understanding where the Next.js middleware ends and where Vercel needs to pick up the slack is also another really hard thing.
How can you think, as a platform, you can help users through this, agnostic to frameworks? Do you think you would get to this point of an SDK or such?
00:23:28 - Brandon Bayer
That's a good question. I'm not sure if I have a great answer for it. I don't think a lot of stuff will need an SDK.
There are some framework-aware things like for Next.js incremental static regeneration that currently does not really work in a multi-instance cluster, or not work well because each instance in the cluster would have a different cache. We're looking at adding basically a hook into Next.js that will unify that cache across all your clusters. So there's stuff like that that we're planning on doing.
But for your thing about custom domains, wildcard domains, we support that as of last week. So you can define your domain as *.example.com. All of those subdomains will route to your app, and then inside the app you can use the host header to detect the domain. It works very similarly to how Vercel does, but we do support that also.
00:24:15 - Christopher Burns
That's awesome to hear. I should really give Flight Control a go. I have to admit, I'm not even on the newsletter.
00:24:22 - Anthony Campolo
I've been in the early adopters.
00:24:23 - Brandon Bayer
Yeah, Anthony's already been in there. We are offering free white-glove migration assistance for a limited time. So we're in that early stage where we're just doing everything we can, doing stuff that doesn't scale, to help people get on board and be successful.
00:24:37 - Christopher Burns
Doing things that don't scale is one of the biggest pieces of advice I can give as a founder. When we talk about technology, we're always so fast to say, yeah, but we should have like 20 webhooks that tell us exactly where this user is along this process and how far they've got and all the billing is already in there. We're making money.
Then your user comes through the door and goes, I don't even like this product. And they walk off and you're like, why? And it's because you've not done things that don't scale. You've not felt the pains before they happen.
I felt this a lot in our funnel, to a certain extent. I can't automate a process until I manually know the problems, manually have done it 20 times, and then it's like I felt the pain so you don't have to. And I think that's a really good thing to think about when building any company. What's the point of automating something if you don't understand the point of it? If the pains that you're trying to avoid by automating it? It's a very big point, but I forgot who says it. Paul Graham, I think.
00:25:33 - Brandon Bayer
Yeah, it's general YC advice, Y Combinator.
00:25:36 - Mina Abadir
And that's a good point because this is how we build our pipelines in order to introduce a new service. We first go and try to build this service manually through the AWS console and see how difficult it is, so we can understand the optimizations and how to optimize the process and how to make it easier for the users. So this is good advice overall.
00:25:54 - Anthony Campolo
Mina, our listeners know Brandon pretty well at this point. You are new to FSJam, so I'd love to hear just a little bit about your background, how you came to know Brandon, and what it was about this project that really excited you.
00:26:08 - Mina Abadir
Yeah, sure. I'm from an engineering background. However, I didn't work in engineering for too long. I worked as a project manager in a few industries. However, engineering has been in the back of my mind.
Ten years ago, I started a side consultancy as a DevOps and development consultancy firm, like a one-man shop. From there, I started to feel the pain of how DevOps is very difficult, how DevOps is very intimidating to small teams who don't have the DevOps background.
There are some tools in the industry today that help with that, but there is no single tool that really had a perfect end-to-end developer experience. I met Brandon three years ago in the entrepreneurship community, Mega Maker. I had been following his journey since the early days of the open-source community. I was there, but I didn't really contribute much at the time.
Then both of us had the urge to start the Flight Control idea. I reached out to him over DM when he started to talk about how difficult it is to productionize your application, and I told him, hey, Brandon, I'm thinking of this idea.
Do you want to partner on that? This is where it all started. I let Brandon continue. He says it better than me.
00:27:24 - Brandon Bayer
He sent me that DM literally the day after I decided, okay, I'm going to build this Flight Control thing. His vision for Flight Control was basically exactly the same vision as mine. We knew of each other, but we didn't really know each other. So it was like a super wild thing.
I got the DM. I'm like, what in the world? We have to talk. It's kind of scary to start a company with somebody that you don't really know, right? But when something like this alignment happens, you have to explore. It turns out we are like the best co-founder pair possible, in my opinion. We're so aligned on core values, on product vision. Our skills fit together so well. It's been a truly awesome journey.
00:28:04 - Anthony Campolo
That's really great. And it does remind me a little bit of me and Chris. We had similar ideas about FSJam and didn't really know each other that well. We started it, and now we're a year into this and done all these episodes, and it's worked out pretty well, I think.
00:28:18 - Christopher Burns
I do think personally, starting a company with a friend is a very hard thing to do because you want to remain friends. Starting a company with a stranger is a different kind of relationship to a friendship.
I think it's more like being a parent, personally, not like being a couple. You both love the thing you're building, and you want it to go your way, and you're willing to work together to keep it going and make it grow.
I've never struggled to find people to join me and help me, but I know a lot of people do. Being a founder of a company, I think, is one of the hardest things I've done but also the most rewarding. Sometimes I think when I'm lying in bed, it's like, how am I here? How have I got to these opportunities? But then I think, yeah, but I could go work at a company and make 100K and that would be my life. And I'm like, yeah, but these opportunities are pretty cool.
00:29:11 - Brandon Bayer
There's nothing like being a founder, in my opinion. I value freedom as one of my most important values. The freedom that you have as a founder can be terrifying to a lot of people, but it just makes me come alive, right? There's just unlimited potential, unlimited possibility. I can go anywhere and do anything.
It's just that mix of art and science of figuring out what to build, who to build it for, how to market it, how to sell it, how to price it. It's just an unlimited amount of challenges and problems to solve. And it's so fun if you like that type of thing.
00:29:41 - Christopher Burns
Yeah, I completely agree. But at the same time, founding a company is not for everybody. It's a very particular type of person. But, you know, sometimes it's easier to know you're definitely getting next month's paycheck. Cool.
00:29:54 - Anthony Campolo
We are getting close to the end of our time. I would point listeners to, you have a podcast now called Flight Review, which I've been listening to and really enjoying. So if people want to stay up on what's happening in Flight Control, that's a really great way to do it.
What are some things that you are really excited about that are coming up soon? And what's kind of in the immediate future for Flight Control that people should be keeping an eye on?
00:30:19 - Brandon Bayer
Flight Review, our podcast, is a weekly podcast where Mina and I are just talking about our weekly experience building a company and everything that goes into that.
For what I'm excited about, I'm super excited. We're doing a public launch within a week or two, so we're pushing really hard to get that done. That's going to be a big public launch, like general availability, Twitter, Product Hunt, etc., so be watching out for that.
We're also working on the Blitz Toolkit pivot. We're aiming to have that finished within a month and a half, and so that is in progress.
00:30:50 - Anthony Campolo
So is Blitz not dead?
00:30:51 - Brandon Bayer
Nope. Blitz is not dead. Blitz is still alive and kicking and is coming back for round two.
What we're building here is really this long-term flywheel between Flight Control and Blitz users. It's good for them to use Flight Control, and Flight Control users, it's good for them to use Blitz.
We have a lot of stuff in store for Blitz. A lot of people are really excited about it. We have a lot of good feedback on this new direction. We're working hard. We have a two-product company with three people. It's a busy time for us.
Mina, what are you excited about?
00:31:22 - Mina Abadir
Yeah, so excited about the public launch. We're getting ready for that. We've been hustling for the past few months to build the product that we like personally to use. This is what excites me most.
And Blitz has been a very great product for everyone. I don't hear any negative things about Blitz, only good things. I'm happy that the community likes it, and we're doubling down on Blitz. It's not that we're just, as Brandon mentioned, three people managing two products, so we're doing our best to balance between both, but Blitz is there.
I am seeing Blitz and Flight Control as a suite of products that basically helps the developer take an idea into execution, into launch, so people can actually focus on their product, on the core product, not building websites and applications. This is not the core of every product, so people can focus on what they need to do for their business.
00:32:15 - Christopher Burns
If I was to join today, I don't expect to see both of them merged into one. Or should I expect to see them both separate? What does that look like?
00:32:25 - Brandon Bayer
For Blitz and Flight Control?
00:32:26 - Christopher Burns
Yeah. As in, is it going to be one dashboard, two separate dashboards, two separate complete apps? Or do I expect them all to just be one massive app in the end?
00:32:34 - Brandon Bayer
No, they're very distinctly different. So Blitz is an open source toolkit. This new direction is an open source toolkit for building full-stack apps in any framework. It's got to be JavaScript, but any framework, primarily Next.js for now, and then also Remix, Astro, all the rest of them, Redwood.
But Flight Control is the paid hosting solution for not just Blitz, but for any application. We support any JavaScript application today without a Dockerfile, but then we also support any other language or framework. If you bring your own custom Dockerfile, in the relatively near future, like a month or two, we'll be adding Heroku Buildpack support, so it'll be super easy to run Rails apps, PHP apps directly on Flight Control as well.
So there are two distinctly different products. In some sense, Blitz is like our marketing for Flight Control. It's a distribution channel for bringing awareness to Flight Control, but they are distinctly different products.
00:33:25 - Anthony Campolo
Very interesting. Yeah, I feel like we could do a whole other episode on just what has been happening with Blitz and the direction that's going. But I know that's still kind of early days, so I won't grill you too much on that for now.
I would be curious if someone has a Blitz app today, pre new toolkit. Is that something where it would make sense for them to migrate to the toolkit, or is it just something that they should maintain and then consider switching over to the new version? Is there a migration path there?
00:33:57 - Brandon Bayer
Yeah, the migration will be super easy, and it'll be highly recommended for everyone to migrate to the new toolkit.
One of the big limitations right now is Blitz is a fork of Next.js, and we're stuck on an older version of Next.js. But with this new toolkit, you'll be able to upgrade Next.js at your own will. You won't be tied to a certain version. A lot of the APIs and stuff are going to be extremely similar, if not the same, and we will be automating any changes that are required via codemod. It should be like just a few-minute upgrade from your current Blitz to the new Blitz toolkit.
00:34:28 - Anthony Campolo
Sounds pretty good. Good luck with that. Do you have any other questions, Chris?
00:34:32 - Christopher Burns
What technologies is the Flight Control dashboard built with?
00:34:36 - Brandon Bayer
I bet you can't guess. Blitz.js.
00:34:38 - Christopher Burns
So you're going to have all these problems to solve for yourself as well. You're not only building the boat, but you're also riding the boat.
00:34:47 - Brandon Bayer
Yeah, I did. I converted a Rails app to Blitz. It'd been over a year ago. This time around, building the Flight Control dashboard is like the first time I've been using Blitz for a while.
During the process of building the Flight Control dashboard, I'm just like, I cannot imagine how I would live without Blitz. I love Blitz so much. The developer experience it provides is just super incredible. We're definitely going to be investing in it heavily.
We'll be hiring later this year. Right now we're sort of in this focus mode with just the three of us, but we are going to be hiring more people for both Flight Control and for Blitz, and really just making this whole developer experience, both for building and deploying apps, as awesome as it can possibly be.
00:35:26 - Christopher Burns
Thank you so much for your time today. Where can users find each of you and Flight Control?
00:35:31 - Brandon Bayer
I'm on Twitter as FlyBayer. F-L-Y-B-A-Y-E-R. You can find Flight Control at Flight Control. We would love to have you try out Flight Control, and if you have any confusion or problems, please let us know. We're still early, so any and all feedback is super valuable.
00:35:49 - Mina Abadir
And you can find me on Twitter under Abadir, so it's A-B-A-D-I-R underscore. That's my handle, abadir_.
00:35:58 - Anthony Campolo
Well, thank you both for being here. I've been so excited for Flight Control. I was happy to be kind of in the early group of people trying it out, so I've actually got a repo that's just like a simple little Express app running on Flight Control right now.
We'll also have that in the show notes, and I'm looking forward to maybe writing some content about it, like some getting started guides and stuff like that. Because I've just been a big fan of what you've been working on, Brandon, for a while, and it's been great to get to contribute a little bit to it.
I really recommend people check it out because we've been talking about the issues that we think come along with hosting these types of applications, and so seeing someone actually go out there and try and address them and try and build something to make that experience better, we're all about that. That's what we really love here at FSJam. So yeah, just always been a big fan of the stuff you're working on and we'll continue to support what you're doing.
00:36:51 - Brandon Bayer
Thank you so much. It's been a pleasure.
00:36:53 - Mina Abadir
Thank you so much.
00:37:23 - Christopher Burns
And we'll see you soon, maybe for the main launch of Flight Control, whenever that is.