CTO at insurtech startup on how AI code generation undermined Supabase's core value proposition

We spoke with a serial cofounder and CTO who has launched seven companies across industries and now advises early-stage founders on architecture and engineering hygiene.

The conversation covers why AI-assisted development has eroded Supabase's core value proposition for developers, how non-developer security misconfigurations create structural risk, and where Supabase might still find a defensible future as the backend for vibe-coding tools.

Key points via Sacra AI:

Can you tell me a bit about your professional background and the kind of work you typically do?

I've been a cofounder and CTO for most of my career. I also worked as a software developer and went to law school and got a law degree. Mostly, though, I have started companies—seven different companies now, as cofounder and CTO, across lots of different industries. What I do is take companies from the very beginning to a fully launched, adopted product, profitable, and then sell them.

How does Supabase fit into that journey? Is it something you're using right now, or is it a tool from a previous venture?

It's something I use only very intermittently right now. AI has really changed how I think about doing a lot of development. The role that Supabase has historically played for me just doesn't make as much sense anymore. Given how easy it is to write incredibly effective code very rapidly—and I'm not writing the code, the AI is writing the code—the back-end-as-a-service that Supabase offers is just not nearly as appealing as using either a container-based strategy like Cloud Run, or more full-featured environments like Google's Firebase or AWS's Amplify and AppSync.

When you were using Supabase historically, which of your companies or projects was it for, and what was the primary reason it was chosen?

The last few things I've used it for have been helping entrepreneurs I've been working with, or in cases where I was building quick prototypes—essentially, how do I quickly get something that you can see, work with, and play with? About 18 months to a year ago, before tools like Claude Code, Codex, Opus 4, and GPT-5 were available, Supabase was a way to empower someone who was not a software developer to build something, and it was the right back end for them because it was very simple. I've also used it for internal tools and prototyping. But today, given that I can write really robust applications with AI tools that just do the work for me, Supabase has enough aspects that are just not scalable—or not right for the types of applications I like to build. Being on a hyperscaler or in other environments is just so much better. I don't like the way the security limits work, and I prefer Neon as a Postgres database. At this point, Supabase has really been dominated by these other options.

Could you dig into those security frustrations? Was it row-level security specifically that felt like a bottleneck, or something else about the architecture?

This brings up another topic: multi-tenancy. For the last few things I've built, I have not wanted multi-tenancy within an application. This is a change for me, because I was very multi-tenancy focused for a long time—especially when I built data businesses, where it inherently makes sense to be multi-tenant for your clients. But in building software as a service used by multiple customers with serverless back-end services, it's become so easy over the last ten-plus years to give every client their own AWS account or Google Cloud project. Those have been incredibly powerful as a way of handling isolation.

When you were looking at Supabase for those prototypes or internal tools, did you find that their project-based structure made that kind of isolation difficult to manage compared to just spinning up a fresh Google Cloud project?

Absolutely. Supabase is not built to make those sorts of infrastructure changes via API or infrastructure as code. Supabase really lives more in an almost 2012 back-end-as-a-service paradigm—like Firebase originally, or even Parse before it was acquired by Facebook.

Since you've moved toward Neon for the database layer, how are you handling the other pieces Supabase usually bundles—specifically authentication and file storage—when you're building these siloed applications?

I've got a few different approaches. For my company Branch, I've built on AWS using AppSync, DynamoDB, Lambda, and Cognito. That's a really great stack—Cognito integrates really well with AppSync for permissioning. I've also built on Firebase using Firestore and Firebase Auth, which has a really nice level of integration, though its security model is slightly less strong than the AppSync/Cognito one.

For any new application, the question is what makes the most sense. If you're building on Firestore or AWS, using their native auth makes a lot of sense. Back in 2016 I built applications with third-party auth like Auth0, and I'm familiar with solutions like Clerk, but I don't like those for uptime reasons. None of those providers can deliver sufficient uptime in my experience. Auth0 was routinely a problem for us, and I really haven't seen a material improvement since then. I see Clerk outages on a regular basis as well.

When I'm building in the pure container-based world, I use existing auth libraries within those container products. I'm generally building verticalized software as a service—software that handles very specific workflows that are painful for companies, with at most a couple thousand users. A lot of times these clients want to run the software on their own private cloud. So I need to package the application as one stateless container, connect to one database, maybe use SendGrid for email, and that's about it.

For those applications, I use TypeScript on both the front end and back end, with React, Vite, and Material UI. I use the MUI X data grid specifically because so many of these verticalized SaaS products are data-heavy—they need to show a lot of data results, filter tables, sort tables, export tables, and paginate through large datasets. It's a simpler stack: everything in one container, running statelessly, connected to something like Neon, or if it's running on-premises, the client will stand up a PostgreSQL database server for it.

Did Supabase's reliance on PostgreSQL extensions and its specific GoTrue auth implementation factor into your decision to move away? Did that feel like too much lock-in compared to a standard container running a library-based auth?

For those on-premises applications, absolutely—there's no way Supabase could have been in the discussion. For the applications I build on AppSync or Google Cloud, Supabase is just too limited. The way Supabase integrates auth with its application layer and the database is clunky—much like Parse's integrations were. It's just not as effective as the more rule-based security models you get with Firebase or AppSync. But the bigger problem is simply that Supabase can't run on-prem or in people's private cloud accounts. And when comparing it to Amazon and Google products, those products are embedded within their ecosystems, have so many more features, have far better infrastructure-as-code support, and make single-tenant apps so much easier that there's really no reason to use Supabase for any of those production applications.

Since you've mentioned using Neon in some of these newer, more portable stacks, does Neon's database branching actually factor into your workflow, or is it more of a nice-to-have?

It's a nice-to-have. When we build on Firebase or DynamoDB, there's really no need to branch databases—there aren't really database migrations. These are key-value stores and document stores. Generally, we would never change the type of a field; you're just adding things and deprecating things out of the structure. When we build containerized apps with relational databases, we use something like Drizzle with PostgreSQL migrations in TypeScript, and we just don't run into that problem.

My own feeling is that the database branching concern is where tools like Vitest and PlanetScale come from—it's born out of a belief about how everyone should be building that assumes a development model most teams simply don't have. Very few teams, in my opinion, have enough developers to run into those kinds of collisions. We also just aren't making the kind of rapid, problematic database changes that branching is designed to protect against. We do give every developer their own Amazon account so they can make whatever migrations they want on what they're working on at a given time. Maybe in an AI-heavy future we'll run into some kind of collision that requires branching—but in my experience over 30 years of building companies, database branching has always struck me as a theoretical problem that people get really excited about solving, but that has never actually been a challenge for the teams I run.

When you're using AI tools to scaffold these containerized apps, do you find that they default to suggesting Supabase, or do they handle your preferred TypeScript container approach just as easily?

My preferred approach works really easily with those tools. I haven't actually tried asking Claude Code or Codex to build on Supabase—when I go to those tools, I've usually thought ahead of time about what stack I want. I'll outline the stack and say here's what I want and why, and ask the AI to question whether I'm making the right decision. I usually ask for exhaustive questions, and I end up getting something like 30 to 40 clarifying questions at the start of a new application. In essentially 100 percent of cases, the core stack I'm suggesting gets confirmed, and then we get into details like API design, whether to use Next or React, and so on.

That said, I've advised a number of startup founders who have said they built on Supabase. So it's definitely coming from somewhere. That probably reflects the fact that when we were hand-coding more, Supabase eliminated a lot of what was really painful about going from nothing to having something you could access, work with, and see in a dashboard. Now that that barrier is basically completely eliminated by AI, the conditions that would lead someone to choose Supabase just don't exist the same way anymore. It turns out it's now just as easy to get a fully containerized application set up with auth, end-to-end testing, unit testing, great design, full library support, and totally production-ready—you just do a prompt, answer 40 questions, wait a couple of hours, and there it is.

What do you think is the biggest risk for Supabase right now?

The 0-to-1 problem they made easier can now be accomplished with basically the same amount of effort and cost using something like Google Cloud Run and a full stack you'd actually want as a developer.

There may still be a great place for Supabase with non-developers—vibe coders, people using tools like Lovable or Bolt—who would still find that hyperscalers are complicated and difficult to work with. If the only reason you're choosing AWS or GCP is to run an application that Supabase could handle just fine, and you don't know those hyperscalers at all, then Supabase is simpler, has cost controls, and is easier to understand. It may still be a good back-end hosting platform for people who don't know hyperscalers and just want to go build apps.

But I'm much more focused on the question of: if you are a software developer, how do we give you superpowers? In that world, Supabase just doesn't make sense. For non-developers who don't want to learn all the developer things, there may still be a good world for Supabase—although I think it needs to be more tightly paired with something like Lovable or Bolt. There needs to be an all-in-one product where you can do all your AI prompting and have everything set up and running. Targeted at non-developers, that's possibly where the future core sweet spot is.

When you see startups that are already using Supabase grow, do they ever hit a breaking point where they have to migrate off? Or do they usually stick with it and deal with the clunkiness because migration feels too painful?

I advise all of them to move off—specifically, to Firebase. Firebase with Firestore, using it as a document database with built-in auth and even using Gemini, is just much less likely to cause problems. Every time I meet someone in that situation, I tell them to migrate to Firebase, because it's going to scale, it's going to work better, and they're not going to end up with a really weird database structure.

Essentially everyone I've mentored who is not a developer and is vibe coding does not understand database design, and AI code generation is not great at designing databases properly over time. A document database just fits better because the mental model is simpler—there are users, and there are the requests they have. That fits the format that MongoDB pioneered, and that Firebase Realtime Database, Firestore, and DynamoDB all do really well. When I look at the database structure of a Supabase project, it's typically not good, and neither are the security rules or the infrastructure-as-code setup. It's just much, much easier for me to advise a migration to Firebase. The infrastructure-as-code part is so much cleaner there, and the project ends up better organized overall.

How painful is that transition? Is it a rip-the-band-aid-off weekend project, or does the way Supabase handles auth and storage make it a multi-week headache to untangle?

Usually within a week they've come back and said it's running on Firebase. It hasn't been nightmarish for the four different apps I've seen move over.

When those founders come back after that week on Firebase, what's the first thing they usually tell you is better or easier?

They feel like they've built something better. From my perspective, it's just a lot easier for me to review. My goal is to pull up a repository and run it through a bunch of questions with Claude Code. When a project is on Supabase, there's quite a lot of stuff that's just not fully in the codebase—it doesn't have the infrastructure as code, it doesn't have the same hygiene. I push people to have end-to-end tests built with Playwright, unit tests, protected branches, linting—all of it running properly. All of this fits much more naturally into Firebase, and it makes it very easy for me to look at the security rules and identify problems, all within one clear repository defined in a way that anyone can understand.

In my head, it's a bit like PHP. When somebody says they have a PHP project, I'm thinking it's probably a dumpster fire of copy-pasted code, massive repetition, and massive security bugs—something that's going to need patching every week because of problems inherent to the ecosystem. There are PHP fans who will point to great applications, but in general practice, PHP applications tend to accumulate massive technical debt, massive repetition, and terrible security problems. My overall experience with Supabase, and what I see when these projects move over to Firebase, is similar: once they're on Firebase, we've finally got something we can really work with—make sure is secure, make sure is scalable, make sure has proper testing and a clean, professional, modern structure.

What is the specific thing in Supabase that is hardest to audit? Is it logic being tucked away in Postgres functions and RLS policies rather than being visible in the application code?

It's that, plus the database structure decisions themselves. It's the potential for having front-end code in a different place from the back-end code, and not being able to share packages, type definitions, and functions between them. When front end and back end are both TypeScript, you want to share all of those things. And all of this comes down to the conventions that emerge when AI tools help build for Supabase—they don't set things up so that it's easy for a CTO to understand everything that's going on. There's no default that drives everything from a git repository the way there is with Firebase or AppSync.

When those founders come to you, is the technical debt and lack of hygiene always the primary reason you push them to migrate, or is the Supabase bill itself ever a point of friction?

The primary driving factor is that if they want me to look at something, spend time with it, and say it's good—they need to move off Supabase. Whatever was in GitHub before tends to be in a much better state once it's moved to Firebase. I get them set up with a prompt that outlines everything we need, and it's just a fundamentally better situation from which to build something secure, scalable, and properly tested.

If Supabase were to pivot and lean into the vibe-coding future—becoming the invisible engine for tools like Bolt or Lovable—do you think they can survive as a standalone business? Or will the hyperscalers eventually build better vibe-to-cloud on-ramps that make Supabase redundant?

I think that is a viable place for them. I don't think AWS has the ability to do it—Amplify is just not great, and there's a lot about AWS that is starting to atrophy. Google has done a much better job. If anyone can do this, I think Google might be able to build a product, because they have the LLMs, they have Firebase, and they have a lot of great tools they could keep within their infrastructure. But the challenge is that the permissions model for Google Cloud is a nightmare, so maybe they'd need to keep it entirely within Firebase—and I think that's still probably excessively complicated for non-developers.

So there's an opportunity for a platform meant for people who don't know how to code and aren't going to learn—a platform with its own simple paradigm where you just talk to it and it handles the front-end hosting, database, backups, scaling, mobile apps, everything. I think that's a very viable space. What I don't know is whether Lovable or Bolt couldn't just build that themselves. Maybe the right move is for someone like Lovable to team up with Supabase and an LLM provider like Anthropic or OpenAI and create an all-in-one destination. Lovable may already be building this. But a one-stop service where you can do all of this is, I think, the key.

For a developer who does know how to code but wants to move at AI speed without unauditable code, is there a specific tool or framework that's getting the hygiene-plus-speed balance right? Or is the answer always custom containers on a hyperscaler?

I like the AppSync/Amplify ecosystem on AWS. I like the Firebase ecosystem on Google. And I like Cloud Run for containers on Google—if I build for that, it can be moved onto someone else's account or even onto Kubernetes without a lot of effort. Those are the best options. If you have any engineering knowledge and experience, I don't know why you wouldn't choose any of those, given how easily and effectively AI tools like Claude Code and Codex can build for them.

Is there anything else about your experience with Supabase or the way you see the back-end landscape shifting that we haven't touched on?

No, I think it's been pretty comprehensive.

You mentioned that when you're advising founders, you find their Supabase security rules are almost always misconfigured. Do you think that's a failure of the Supabase UI and documentation, or is it an inherent danger of putting the security layer inside the database where non-developers can't easily see it?

It's an inherent problem of having non-developers interact with security concepts they have no actual understanding of—or framework for thinking about.

This transcript is for information purposes only and does not constitute advice of any type or trade recommendation and should not form the basis of any investment decision. Sacra accepts no liability for the transcript or for any errors, omissions or inaccuracies in respect of it. The views of the experts expressed in the transcript are those of the experts and they are not endorsed by, nor do they represent the opinion of Sacra. Sacra reserves all copyright, intellectual property rights in the transcript. Any modification, copying, displaying, distributing, transmitting, publishing, licensing, creating derivative works from, or selling any transcript is strictly prohibited.