Interview of Brandon Bayer - Creator of Blitz.JS
Hi Brandon, can you introduce yourself to our dev community?
Hey! I’m the creator of Blitz.js. I’m based in Ohio, I am an airplane and helicopter pilot and love doing outdoor activities.
So, you are the creator of BlitzJS - can you tell us more about it?
In short, Blitz is the Ruby on Rails equivalent for Javascript and React. It extends Next.js to add lots of awesome power features for doing fullstack. It’s a batteries-included framework that has everything you need for fullstack including database, authentication, code generation, etc.
What makes BlitzJS unique? Who and why should use it?
The keystone feature of Blitz is the “zero-api” data layer. We abstract the API layer into a compile step so as a developer you just write functions that run on the server (to talk to a database, etc), then import those functions directly into your React components, and then it just magically works. No messing with REST or GraphQL APIs!
This is mainly why devs report Blitz makes them 5-10x more productive than other stacks.
Blitz is perfect for any web app. We have lots of small and medium startups using it as well as larger enterprises like Algolia and an Australian energy company.
What are the biggest challenges you are facing in building BlitzJS?
Npm is garbage 😂 But for real, node_modules and package managers cause the most headaches and problems for us. All the package managers result in different organizations inside node_modules which can result in weird bugs in our code. We encounter bugs in npm/yarn that we have to workaround. We often get reports from people that something isn’t working and it’s a npm/yarn specific thing in their environment. Usually switching to a different package manager will fix their problem.
Why did you build this product? Can you share your vision with us?
I got into web programming through Ruby on Rails. And then I spent 4 years doing React/node consulting. And I came to really miss the DX that Rails provided and wanted something similar for React/JS.
How many are you in the team, and how many external contributors do you have?
For 1.5 years, it was mainly just me with a long tail of OSS contributors. A couple of months ago we hired Aleksandra Sikora, a former engineering manager at Hasura, to be the Lead Blitz Maintainer. We now have over 375 total contributors!
Are you looking for more external contributors? What kind of contributions are you looking for?
Yes!! We love contributions of all kinds. Bug fixes, features, feature ideas, helping answer questions in our Discord, etc. See how to get started here: https://blitzjs.com/docs/contributing
What are your plans for BlitzJS in the next 12 months? (hiring, product development…?)
The first thing is to get to 1.0 which we are very close to. We’re essentially at 1.0 release candidate phase and should have that out within a month. Then we’ll be working hard to keep improving and adding new features. One key area will be making integrations with mobile apps better. Probably will hire a few more Blitz maintainers over the next year.
I saw that you are working on a cloud platform - “Flightcontrol”. Can you tell us more about it? What is it? And when do you plan to launch it?
We are building Flightcontrol to be the best deployment platform for Blitz, Next.js, and Remix. Similar to Qovery it will deploy infrastructure on your own cloud account. We’ll be custom tailoring the infrastructure to Next and Blitz and supporting both containers and serverless.
Any day now we are ready to start letting our first early access insiders in to start kicking the tires. We’re aiming to be ready for production workloads by end of January.
Do you have any advice for other founders trying to build open-source projects?
Open-source is hard! Best thing you can do is (1) do good marketing, (2) always be marketing, (3) be intentional about building an awesome community from day 1, and of course (4) build things developers love to use.
What is the thing you are the proudest of (it can be unrelated to Blitz.JS)?
Probably it would be Blitz. It really transitioned me from a mostly no-body to someone with a much higher profile in the JS community. When I started it, I very much did not feel like a framework expert. And it was something I really had no idea how to do. But I kept pressing through and figured it out as I went!
What is your favorite programming language? Why?
Typescript! Was Javascript, but Javascript is like running through a maze with your eyes closed. You have to run into walls before knowing to turn. Open your eyes and use Typescript and you have much less pain :D
Are you more PostgreSQL or MongoDB? Why?
Postgres! Because most apps you start have varied and unknown query patterns. You should only use NoSQL once you know your query patterns and can benefit from NoSQL perf optimizations in those cases.
What are the top 3 tools you enjoy as a developer?
- Vim
- Alfred
- Karabiner Elements (for key remapping)
Do you have any favorite cloud service providers? Why?
We are REALLY enjoying Temporal for managing robust background workflows. If background queues are like promise callbacks, then Temporal is like async/await.
What do people not know about you? Do you have a superpower (I saw on Twitter that you have a private pilot license - it is a kind of superpower no? :))?
Haha, I do have my pilot license. Been flying Airplanes since I was 15. Now I’m ⅓ of the way through helicopter training which is just the most phenomenal experience ever! Other than that I would say my superpower is being able to not do something for a long time and then come back and pick it up again without difficulty.
Should we say Blitz or BlitzJS?
Blitz or Blitz.js
Do you want to thank some people in your community?
Big shout out to Rudi Yardley, Adam Markon, and Simon Knott for being early, very impactful contributors to Blitz!
Who should we invite for our following Tech Story interview?
https://twitter.com/aleksandrasays - she is a Typescript wizard! Would be interesting to learn how she got into TS, how she got so good, etc.
Do you have something to share with our dev community?
Free stickers!! Shipped anywhere in the world. Enter your address here: https://blitzjs.com/stickers
Check out BlitzJS - a popular open-source React framework.
Read our previous interview with Oliver - CTO and co-founder of Medusa.
.svg)
.svg)
.svg)
Suggested articles
The shift from AI copilots to autonomous agents is redefining infrastructure requirements. Discover how to build secure, stateful, and compliant Agentic AI systems using Kubernetes, sandboxing, and observability while meeting EU AI Act standards
Effective Kubernetes management in 2026 demands a shift from manual cluster building to intent-based fleet orchestration. By implementing agentic automation on standard EKS, GKE, or AKS clusters, enterprises eliminate operational weight, prevent configuration drift, and proactively control cloud spend without vendor lock-in, enabling effective scaling across massive fleets.
A Kubernetes single pane of glass is a centralized management layer that unifies visibility, access control, cost allocation, and policy enforcement across § cluster in an enterprise fleet for all cloud providers. It replaces the fragmented practice of switching between AWS, GCP, and Azure consoles to govern infrastructure, giving platform teams a single source of truth for multi-cloud Kubernetes operations.
Deploying a Docker container on Kubernetes requires building an image, authenticating with a registry, writing YAML deployment manifests, configuring services, and executing kubectl commands. While necessary to understand, executing this manual workflow across thousands of clusters causes severe configuration drift. Enterprise platform teams use agentic platforms to automate the entire deployment lifecycle.
At enterprise scale, managing provider-specific Kubernetes YAML across multiple clouds creates crippling configuration drift and operational toil. By adopting an agentic Kubernetes management platform, infrastructure teams abstract cloud-specific configurations (like ingress controllers and storage classes) into a single, declarative intent that automatically reconciles across 1,000+ clusters.
To stop GPU costs from destroying SaaS margins, teams must transition from static to consumption-based infrastructure by utilizing Karpenter for dynamic provisioning, maximizing hardware density with NVIDIA MIG, and leveraging Qovery to tie scaling directly to business metrics.
AI is helping developers write more code, faster than ever. But writing code is only half the story. What happens after? Building, deploying, debugging, scaling. That's where teams still lose hours.We're building Qovery for this era. Not just to deploy your code, but to make everything that comes after writing it just as fast.
.webp)