Traditional software engineers are now building AI applications.
But the tools used for building CRUD apps may not work for reasons such as:
- GPUs for training/inference
- Libraries can be BIG
- Long-running, intensive jobs (e.g. processing files with ffmpeg)
Erik initially set out to build tools for data people. But has found way more success with software engineers.
Developers don't like change
LLM wrappers have been taking over the internet (or at least YC applications). I, myself am guilty of building one. With one API call, you have AI.
But, the reality is that most applications will need more than just the OpenAI API. And so we exit the world of CRUD apps and enter an overwhelming world of machine learning and infrastructure.
I believe developers will pick tools to minimise change and learning in this order:
- The things they already use for CRUD apps (if they can be used)
- Tools that feel like the tools they use for CRUD apps
- Tools they have heard of that do things differently
Be the firebase for AI developers
Front-end-leaning engineers who could previously rely on Firebase may now need to move to AWS to build their features that use AI. Even if they use lambdas, there's still a learning curve for services like IAM, SQS, GitHub Actions etc. If they need to use EC2, that's a whole lot of new things. And that's before thinking about training your own models or running your own inference.
That is of course, unless there are tools that make developers feel like they're using Firebase but give them the power to solve the above challenges.
Writing code for computers is easy
As Erik puts it, writing code for computers is easy, writing code for humans is hard.
You need to think about what their mental model is and how they would want to write code.
One example is Erik learned that his users wanted to run their code locally. But he questioned why they care about local development. The reason he realised is because it's "f***ing slow in the cloud". So, he instead focused on making running things in the cloud take a second. And that means no complex local setup.
But don't be the firebase of AI
If I'm your target audience, "Firebase but X" is a good way to communicate and probably a good way to think about product development, too.
But that's because I used Firebase a lot back in the day, and it forms a mental model for me. It's why Supabase resonates with me ("open source firebase alternative").
But you don't have to be the Firebase for AI developers because I'm probably not your target audience. Modal Labs don't even refer to themselves this way. The main point is that in this fast-changing world, listen to your users and leverage their existing mental models.