Why FastAPI Labs - Why FastAPI Cloud

Why did I start a company, why now, why this product, why raise money?

Why Not Start a Company?

I avoided building a company for a long time, similar to how I avoided building FastAPI (or Typer, SQLModel, Asyncer).

I really wanted there to be something that solved the problem already.

I always default to teaching how to use existing tools when possible, rather than building something new. I even ran one of the most popular websites teaching how to use a (now soft-obsolete) simpler alternative to Kubernetes.

But when using a new abstraction is simpler, faster, and safer, it makes sense to build that new abstraction. That’s why I built FastAPI and my other open source projects.

When I first started playing with servers, I appreciated the power of having a raw remote Linux machine and being able to do everything by hand through SSH. But at the scale of the internet, serving users required being able to scale beyond one machine, account for failures, etc. That little detail became a giant topic.

The Problem: No Right Abstraction

Now, in the current cloud landscape, for the vast majority of people, using Kubernetes or alternatives directly is the wrong abstraction; it’s just too much.

And many other tools that provide some layer over cloud primitives are giving you something different from what you, as a Python developer, need. For example, some might try to give you a way to set up your app for the cloud with extra config files that were designed years ago, probably for Ruby, a completely different ecosystem. So, instead of learning Kubernetes, you’re learning the quirks and details of another cloud product that is not as optimized for Python, your workflow, and your apps as it could be.

I wasn’t happy about this.

I could take you from knowing the basics of Python to having an app with an API pretty much production-ready in a short time, just follow the docs, and you’re ready in days or weeks.

But then deploying… You were on your own. I taught you lots of the concepts, but I could only take you so far. I didn’t have a way to help with that. I didn’t like that.

Inspiration

Then, seeing the developer experience and value that you could get from similar products in other areas, for example, in the frontend world, from Vercel, Netlify, and Cloudflare. It’s just so much simpler to use their products than to build the entire cloud infrastructure for frontend, even for just a static app.

I was skeptical of products like that at first. But that developer experience felt right. I felt confident that it was all robust, performant, and well done, and I didn’t have to worry about it. That certainty felt right.

But we didn’t have that in Python.

A Pattern

I also noticed the same pattern that led to my open source projects (FastAPI, Typer, SQLModel, etc.).

I saw something difficult, daunting, I really hoped someone else would have solved it, and in the search for that hypothetical solution, I ended up learning a lot about the original subject and challenge.

And then, after lots of trying, I concluded it was not really solved yet, at least not to my satisfaction.

So I ended up building it, to have something as simple and intuitive to use as possible, which I wished existed when I started searching for it.

In all cases, I was targeting myself as the user. I wanted to use the final product of that effort. That allowed me to optimize everything for that, for me as a user of the product.

It’s the same with FastAPI Cloud: I’m the first user, and I have been wanting this to exist for years.

What Product

I played with the idea of building a company or a product for years, but (until now) no specific idea seemed right.

I didn’t want to make “premium features” in FastAPI. The constant conflict of deciding what to make open source and what to make commercial doesn’t sound fun.

Selling enterprise support as the main and only product could come with an intrinsic incentive to have bad docs, so people would want to pay to be told how to do things. I don’t like that, and you probably know it, as you probably like my docs (I hope 🤞).

Every time I could come up with something useful and worth building, it just had to be open source (hence Typer, SQLModel, Asyncer, etc).

Meanwhile, deploying to the cloud kept being painful, especially when done properly, in a way that scales, with HTTPS and good security by default, etc.

A Cloud for FastAPI

Building an entire cloud was not something I could do alone. I needed a team, I needed resources to pay them, to pay the cloud bill, and all while also working on open source.

So, I accidentally put myself in the right position to build a VC-backed startup. Building this product required a lot of resources, but there are also a lot of potential users (you 😉).

And building a cloud had this very nice property: there’s not much overlap between the open source parts and the commercial product itself, so there’s no conflict of “what goes to open source and what do we charge for”, it’s all clear.

Even better, the more people who are able to successfully use FastAPI and Python in general, the more potential clients for the product, so there’s an intrinsic incentive to keep the open source projects healthy and serve even more users, with good docs and good features.

So, that becomes our marketing strategy, to make our open source even better than it already is, and build new open source tools to cover more use cases.

We invest marketing resources into just building good open source software, and let our happy users be our best ambassadors.

This way, having good open source is good business for the company.

And at some point, you, as a user (or your company), have to pay for some cloud infrastructure either way. So why wouldn’t you pay the one that gives you the best value, adapted right to your needs, the one where you are the fastest building your product, and also the one that, by using it, sustains the tools you use to build and helps the ecosystem in general?

So, you get better tools, a better cloud, and we get a sustainable business to keep funding the same tools, and everyone can build more and better stuff. Everyone wins.

That’s why I started a company, FastAPI Labs, to build FastAPI Cloud, and make that “deploy FastAPI to the cloud” step as intuitive, efficient, and tiny as it should be.

You code. We cloud.