By playing, you agree to uListen's Terms and Privacy Policy and YouTube's Terms of Service.

The egoless culture that built Supabase | Paul Copplestone (Co-founder, CEO)

In this episode of In Depth, Brett sits down with Paul Copplestone, co-founder and CEO of Supabase, the open-source Postgres platform now serving more than seven million developers.

Paul CopplestoneguestBrett Bersonhost

Jun 25, 20261h 2mWatch on YouTube

Summaries, chapters, transcripts, and FAQs on this page are made by uListen, not YouTube.

Great conversations run long. Their best ideas don't have to.

uListen is free on iPhone, iPad, Android, Chrome, and Claude.

See how

Transcript

60 min read · 11,906 words

0:00 – 1:32
Introduction
1. PCPaul Copplestone
  We thought we were getting DDOS'd at the time, actually, because we just saw this customer launching lots and lots of databases
2. BBBrett Berson
  For today's episode, I'm sitting down with Paul Copplestone, co-founder and CEO of Supabase, the open source backend platform that millions of developers now build on. The company started as a side project, and now it's the backend for a huge slice of the internet
3. PCPaul Copplestone
  It was obvious to me how hard it was for developers to use databases. If the problem exists, then the opportunity exists
4. BBBrett Berson
  But it wasn't always like this. Before Supabase, Paul built other startups that never took off in the same way
5. PCPaul Copplestone
  There's something, like, painful about the chewing glass of trying to find product market fit, and you're trying everything, and sometimes you just don't know what else to do
6. BBBrett Berson
  When AI app builders like Bolt and Lovable launched, every new app needed a backend, and many chose Supabase
7. PCPaul Copplestone
  These are the tools that are using more of the CLI MCP type workload now happening off a base of seven, eight million developers
8. BBBrett Berson
  In our conversation, Paul reverse engineers why Supabase worked. He shares why he refuses to lock in customers and how he's building towards self-driving databases run by agents
9. PCPaul Copplestone
  We want to build a generational database company
10. BBBrett Berson
  He also gets into the chaos of hypergrowth and how he tackled the success problems that come with scaling too fast without losing himself in the process
11. PCPaul Copplestone
  I wanna look back at the end of my life and think, "Oh, not only did I build a big fucking company, but I also did it my way
12. BBBrett Berson
  Let's dive in. [on-hold music]
1:32 – 7:14
Why Paul's earlier startups were never destined to be huge
1. BBBrett Berson
  You worked on multiple companies before you started Supabase that were seemingly less successful than this company, depending on sort of how you measure it. What are your reflections on, like, the value of a good idea or a few of, like, the foundational things that clicked into place with this company that didn't click into place with other companies?
2. PCPaul Copplestone
  Well, I think a successful startup takes, like, 1,000 things to go right, you know, and a lot of luck. The first ones were probably never destined to be as big. The ambition behind them was not as, as large. So, you know, they could have been successful in a local maxima
3. BBBrett Berson
  Why is that?
4. PCPaul Copplestone
  Well, they're geographically constrained, for starters. The first one was a marketplace in Southeast Asia. The reason why that first one didn't go well was it didn't have pure product market fit. We're modeling against, uh, one here in the US actually called Thumbtack. Which is... Of course, markets are all different. The way things operate, there's a different mentality to how you, how you do things in the US versus, say, even Ma-Malaysia or, uh, Thailand
5. BBBrett Berson
  When you were working on it in the early days, did you have a less ambitious mindset-
6. PCPaul Copplestone
  No
7. BBBrett Berson
  ... versus where you started? All of that was... You're just saying that it turned out to be less ambitious, not the intention.
8. PCPaul Copplestone
  Yeah. I mean, the mindset's still the same. I mean, the, um, viciousness, could we build that to be a hundred billion dollar company? No. So I think my, my, uh, ability to assess a market dynamic is much more honed now. In fact, I think I even worked, I would say, harder on, on that when I was pulling 90-hour weeks or something like that to, to make it work. So we're definitely ambitious, and I learned a lot from that one. I had a co-founder who was extremely ambitious, great salesperson, uh, extremely good at fundraising, and all of these things were assets that I picked up from him
9. BBBrett Berson
  What about sort of the second experience?
10. PCPaul Copplestone
  Yeah, it's funny 'cause the journey kind of, uh, trickles onto Supabase. My country manager for my first startup said, "I'm building this company, and it's going to be..." He explained it, and it's kind of like an office management tool, but it also owning the services. So very similar to the first one, but fixing many of the... or de-risking a lot of the things that were in, um, in the first one. And he had some moats, like some permission from the government to do, uh, certain things. So that was good. But I said to him, "Look, I'm a developer. I'm, I'm gonna launch a, a dev tools company."
11. BBBrett Berson
  That's what you were thinking about doing at the time?
12. PCPaul Copplestone
  Yep. Yeah. He said to me, "Well, just give me a couple of years. Come, come, like, brainstorm, like, um, build it and just, like, build with us on the side, or, like, in-inside." And so that's actually where I started building. I took a lot of those learnings from all those companies that I was launching, and then I kind of honed the tech stack and I built the second company. It's called Nimbus. I built Nimbus with, with the same tech stack, and that tech stack now is what is Supabase
13. BBBrett Berson
  Talk more about w- how that actually unfolded
14. PCPaul Copplestone
  I was building a chat application. As I said, many of them actually in Southeast Asia operate via messaging. And so essentially what I was building was a, a, a platform, but it felt more like a chat app. We were using Postgres for most of our database, uh, workload, but then for the chat side, I was using Firebase 'cause it's got this nice real time functionality. It's very, very cool actually. But as we started scaling up, I hit some, some scaling limits on that particular piece. And then I thought, "Ah, all right. I have to figure out how to fix this." And then I was looking at our tech stack and, uh, Postgres, and I realized I could build this real time feature on top of Postgres itself. Uh, I needed to use this, uh, framework, a language called Elixir, framework of, uh, Phoenix, and I built it, and I open sourced it, and it, it worked very well for our use case. And it started getting some traction on Hacker News, just the open source part of it. And so I thought, "Okay, timing seems good. There's interest, developer interest. I know what I wanna build. I wanna build a database startup." I knew I wanted to do it on Postgres, and so when all of these things just, um, lined up, I reached out to my now co-founder, who I had met at Entrepreneur First, and I had lived with him, and I said, "This is what I'm gonna build I thought at the time, uh, again, to de-risk things, I thought, "I'm going to build a, the most Y Combinator-friendly team and apply for Y- YC, and that will help from a dev tool point of view." I think that's the pitch that actually convinced him he really wanted to go to YC. And so we started, and we were fortunate to get into YC very early on.
15. BBBrett Berson
  When you sort of came across this opportunity, and you were starting what is now Supabase, was it very obvious to you? And was it high conviction, or was it like, "Well, this seems interesting. I could kind of see it going..." Like, what was the feeling in your own psychology at the time?
16. PCPaul Copplestone
  It was obvious to me how hard it was for developers to use databases. Yeah. And I just knew if the problem exists, then the opportunity exists. What I couldn't have picked is how successful Postgres has been. We definitely rode that wave, and hopefully, we contributed a little bit to that wave as well. So in that way, we've had a lot of tailwinds, and we've been pretty deliberate to try to capture as many of these tailwinds as possible. So each time, it feels like the opportunity is getting bigger and bigger. I felt like there was a
7:14 – 9:54
Unlearning the "tall poppy" mindset and going all-in on async
1. PCPaul Copplestone
  definitely a, a big business in it, but probably not, or, or definitely at the time, not at the scale that I know we can reach now.
2. BBBrett Berson
  You were talking a little bit about this, but how were you different as a founder when you started Supabase versus when you were working on your, your first company?
3. PCPaul Copplestone
  Well, first of all, when I started on my first startup, I don't know how familiar you are with the Kiwi mindset, the New Zealand mindset. I'm, I'm from New Zealand, and we've got this thing called tall poppy, where you don't, you don't ever want to be the tallest poppy because then you, you get cut down. So you always make yourself smaller or... I don't know. It's a hard culture to explain. I quickly unlearned that in my first startup. I remember, um, my co-founder, as I said, he wa- he was very good at fundraising. I, I learned a lot from him, um, how to fundraise, and it's a little bit like sales. Uh, it's slightly different, um, but I had to learn that. So, so actually, that's one thing. I treat the process of fundraising and building a business as two distinct things. Now, hopefully, both of them you do phenomenally, but you could do one or the other separately quite well. I learned really, um, the dynamics of fundraising, investors, why it's important, when to raise. I also learned the value of not blitzscaling too early. So find product market fit before you blitzscale. I probably learned that lesson a little bit too hard at Supabase. We're very small, and we've got to ramp up really fast, um, for our scale. Yeah, I held that lesson too long, I think, at Supabase, where, you know, we've got a lot of growth a- across everywhere, and a lot of people are stretched. But it was good to see that i- internally at my first startup, like how we hired, um, maybe too fast on too many areas that, that didn't matter. What was good on that one, my, uh, co-founder was very diligent about keeping the, the bar extremely high. That one has always stuck. I think that one's universal. If you can keep the best people, um... It was at YC yesterday, and someone was saying, "Should I take someone who's high agency, or, or should I take someone who's high performance?" And, like, it's very clear to me. It's, it's both. Like, you just don't compromise on, on any of those. So we at Supabase are a fully distributed team. Uh, we have no offices. So we're in three countries in, in my first startup, and we had an HQ in Malaysia. And whenever I'd visit Singapore or Thailand, they'd always feel like decisions were made away from them because the, the gravity of the co-founders is, is too high. Of course, everyone went f- fully distributed in, during COVID, and then there was a big push to go back in or do hybrid. It was very clear to
9:54 – 12:04
Reverse-engineering why Supabase was an outstanding idea
1. PCPaul Copplestone
  me. No, you don't half-ass it. You just go all in if you're going to do remote. We went completely async, and now actually, I think it's a, a superpower for us.
2. BBBrett Berson
  What about if you take a crack at reverse engineering why Supabase was an outstanding idea that maybe you didn't even fully grok at the time, but now you have the benefit of hindsight? And so, like dissecting it and saying, "Okay, here's actually why it turned out to be so good," how would you articulate it?
3. PCPaul Copplestone
  With the benefit of hindsight, lots of tailwinds. That's always good. Hard problem to solve is also good. We have competition, but it's not like a competitor can spin up. So for example, now if I was building in the AI area, there's a lot of things that are getting launched fast. That means a competitor can get launched fast. Where we are is not in the build space. We're in the operate space. We operate the databases, so it's not just enough to, to launch something. You have to prove that you can operate it over, over many years and, and do it at scale. So there's this kind of moat that was important. We also leaned very hard into our community and the PLG motion, so that was good, not trying to split our focus between let's go upmarket really fast. Um, we've just kept our finger on the pulse of the community and the, the PLG motion, even though we get a lot of pressure all the time to, to move really fast across and, and win all types of workloads. And this was important because as well, Postgres is so versatile. It, it can serve anything that enterprises wanted. You can use it for this thing, that thing, whatever. And so we're often trying to, to find out exactly what their ICP should be and, and only build kind of increments on top. So it's like a onion getting larger rather than kind of splitting our focus all around. So from this point, I think it was beneficial that we just had a lot of market drag, a lot of market pull anyway. And, you know, in my earlier startups, you know, when you don't have product market fit, you lose focus because nothing is clearly winning, so you're, you're jumping around a lot.
4. BBBrett Berson
  What's your definition of product market fit?
5. PCPaul Copplestone
  I don't really have a
12:04 – 13:58
The accidental Hacker News launch and tagline lesson
1. PCPaul Copplestone
  definition, but you kind of just know it. [chuckles] Like when, when things are growing a lot faster and when you're doing nothing, and it continues to accelerate. That's kind of how it feels.
2. BBBrett Berson
  What was the very first moment that you sort of felt that real pull? What was the product maturity at that point? Like, what's the story? If there was a day or a number of days that it felt like the ball started rolling down the hill.
3. PCPaul Copplestone
  I can kind of peg a few key dates at the start of, like, 2020. We got into YC, and we did this accidental launch. Someone put us on Hacker News, and usually you do a launch Hacker News. Someone put us on Hacker News, and it was the day after I changed the tagline. I changed the tagline to open source Firebase alternative, and someone put it on Hacker News that next day, and immediately it went, like, to the top of Hacker News. It was very upvoted, lots of comments. And that was kind of the first lesson in that product market fit often is just like a product positioning fit. Sometimes you can just change some things, and that's all that matters. And there are some people in the world that want whatever you're building, even if it's a niche product. You just kind of need to find them and, and tell them in the right way. So that was the first thing. A, a good lesson as well just on how to position things for developers. From there, a lot of people in those threads said, "Oh, we really need auth." Um, this is a, a product that Firebase have, 'cause we'd now put the Firebase positioning out there. They actually wanted these other things. And of course, I only really wanted to build the database offering. But auth made sense because I thought we could do a better product for the market by putting your auth users in your Postgres database. Actually something that I never really understood from other auth providers, keeping your users outside your database. So we did it, and we managed to launch that before the Y Combinator demo day. And again, like, we just saw the slope of the chart change, and we thought, "Ah, all right. Like, these launches are clearly things that work." So
13:58 – 17:28
Where the early roadmap came from: demand vs. technical taste
1. PCPaul Copplestone
  off the back of that, we said, "All right. Demo day's gone. In three months' time, we'll just move from alpha to beta, and we'll say all the things we've shipped on this one day."
2. BBBrett Berson
  Just keep launching.
3. PCPaul Copplestone
  Yeah, and we just... We, we ship, ship, ship, and then on that day, we just rolled everything up into, like, a, a single page and put it on Hacker News, and it went up again. And we thought, "Oh, that's great. Well, we launched, and why don't we just turn this into, instead of one launch, can we do a launch every day for a week?" And then that was our first launch week, maybe I think four months later. Again, we just kept seeing these 20% bumps each time we would do these product launches. So it felt like, um, sometimes inside those launches, there were some things that fired really well, some things that didn't. And, um, you know, you can tell those ones that have product market fit just have, uh, direct demand.
4. BBBrett Berson
  Did the early roadmap come from people just saying, "I need this and I need that," or did it come from more of a technical taste perspective? Like, you had an opinion on how this thing should work and what we should build, and so you just kind of manifested it in the world.
5. PCPaul Copplestone
  Bit of both. Yep. It was a, a hybrid. So we knew as well, again, because of our positioning, all the things that Firebase had. We didn't wanna do all of them 'cause we wanted to keep the, the database side. And I just thought of some ways to do it, or as well the team had some ideas that they wanted to build, and they seemed to fit. And we largely think in primitives. Uh, we try to offer just pure primitives rather than, than products, and the primitives can be mixed and matched to, to allowing developers to do many, many things. I think the only one that was really, really, like, demanded from, uh, the community was functions. We went through, uh, our edge functions. We went through, like, three launch weeks, and we... People kept saying, "Oh, I hope they launch edge functions this, this launch week." And we were thinking, "No, we, we don't want to 'cause we're a database," and we're telling them, "Use Next.js or use what-whatever you're using." In the end, the demand was so, so high that we had to launch it. And so, yeah. And this turned out to be a, a great product.
6. BBBrett Berson
  When you think about the first year, building the first product, starting to launch, what felt at the time very hard, and what felt somewhat easy?
7. PCPaul Copplestone
  I mean, it was a grind. Slots of schlenk. It didn't really feel that hard, if I'm kind of honest. Once we felt like we had product market fit, I mean, it's all problems of scaling, right? It's really just about navigating community and feature requests and building as fast as you can, and these things are largely exciting, and we had a lot of people, uh, joining the team. I remember, this is how I know it wasn't necessarily hard. A lot of those ex-founders were coming to us, and they were, like, burnt out. I, I remember one in particular who was burnt out from doing his own company for five years. And we said, "Oh, you know, just come help us. We've got so much work to do. Just spend a bit of time if you want. Take a break from your own company." And he came in, and instantly he was reinvigorated because he no longer had to deal with product market fit. It was just solving these cool technical problems for our customers, and he joined, uh, Supabase. Time and time again, I saw this from founders where they were burnt out from, from their own thing.
8. BBBrett Berson
  They were burned out from it just not working, not-
9. PCPaul Copplestone
  Just not working, yeah
10. BBBrett Berson
  ... working on it.
11. PCPaul Copplestone
  There's something, like, painful about the chewing glass of trying to find product market fit, and you're trying everything, and sometimes you just don't know what else to do. Maybe 'cause there is no way to, to get your vision
17:28 – 21:42
Skill vs. luck, and operating like you have $100K in the bank
1. PCPaul Copplestone
  into the hands of the right people. But we didn't have that. We... It was just problems of shipping as fast as we could.
2. BBBrett Berson
  What is your reflection now on the interplay between skill and luck specifically in originally getting into product market fit?
3. PCPaul Copplestone
  Well, it depends on the time of the market. The things that I'm uniquely served to solve might not be perfect for the timing. What happens when you get product market fit is usually-- Or even the funding. Like for example, if I just went out and, and raised a lot of money, then the temptation is, "Okay. Well, let's hire lots of people." 10 people don't help you solve product market fit, right? You have to iterate. You have to do it small. So we're launching a product at the moment, and there's just no engineers on it. It's just a product person engineering it. And people say, "Oh, should we staff this up?" And I'm... I say, "Well, absolutely not." They don't have an i- the idea baked yet And so it needs to be really a, a fast and tight feedback loop. What we did well and what I would do, I think, if I was to start again, is, yes, I'd raise the funds. That's important. But I'd still operate as if I only have 100,000 in the bank account, you know. Where you just gotta iterate really fast with a small group of people to try find that thing, and then you've gotta be really honest about whether you're actually got fit or not. As we've said, it means many things. So whether people will use something, whether they'll pay for something, whether they'll upgrade on that thing, whether they'll want to take it into an enterprise. All of these are, are different stages of fit that you need to de-risk.
4. BBBrett Berson
  What else did you learn, if anything, about the relationship between you as a founder and what you should actually work on? And this may be sort of too reductive, but it sounds like the first company was just not as perfectly fit to you as Supabase. Do you have any reflections on that?
5. PCPaul Copplestone
  I think that's okay because I was the CTO. Me being a techie, of course I wanna work on tech things, but there are so many opportunities [chuckles] outside of the tech bubble that need to be techified. Well, maybe we're seeing that now with AI and that can leak out into these domains, but I don't think they necessarily failed because I wasn't passionate about the space. And in fact, the second one, um, is quite successful. Um, of course, not to the degree that Supabase is, but my co-founder there has done a phenomenal job of scaling it, and I helped him a, a lot. I really like this space. I like helping service workers. But yeah, I'm, I'm passionate about tech.
6. BBBrett Berson
  How do you now approach building new products at Supabase and getting those into product market fit?
7. PCPaul Copplestone
  We could just kind of push things out and, um, people would adopt them, and we didn't have to worry about, you, you know, eight million developers trying something out on day one. Now... And also we've got a very well-functioning business.
8. BBBrett Berson
  So, but back then, it was a little bit more improvisational, and you would have one or two engineers-
9. PCPaul Copplestone
  Yeah
10. BBBrett Berson
  ... work on something that you thought was good, the customers thought was interesting, and just put it out in the world, and that was that?
11. PCPaul Copplestone
  I think in our second launch week, and one of our engineers had built, um, Supabase Storage, somewhere where you could store... I think it was storage. I can't remember exactly. But for storing files and videos and things like that 'cause you can't stick them in your database. And I remember we're about to launch it for launch week, and literally two hours before we launched it, he wasn't happy with the DX of the client libraries, and he just kind of rewrote them and, and launched them after that to be more like Supabase. So it was very much like that. We're just kind of, um, like bouncing ideas off each other, um, trying to make, like, a perfect, uh, integrated suite, and we could test these things out, and we weren't too scared to put something new out into the world.
12. BBBrett Berson
  And so then how does it work today at a n- running at an ad scale business when you're building something new?
13. PCPaul Copplestone
  You have to be able to scale up. That's rule number one. Uh, you probably need billing on it. People will abuse things. Strong security guardrails. There's all these things that you need to think about to... before you can really push it out. And so now where we're moving towards is more like a, a pipeline. Uh, we used to have this pipeline, which is private alpha, public alpha into beta. Now we're thinking, well, just put it out into labs, um, where we'll have
21:42 – 23:10
What actually makes a great developer experience
1. PCPaul Copplestone
  a smaller subset, and people might discover it organically, but it doesn't necessarily have to have the full marketing weight behind it. And then we get feedback from that, and then it can start moving natively into the platform.
2. BBBrett Berson
  What do you think makes a great developer experience? If you had to talk about it in the most concrete, specific way, or you were teaching someone, like, your ideas about what it means for something to be truly incredible from a developer experience perspective, what are the underpinnings?
3. PCPaul Copplestone
  I think the key metric is time to value. You want to get the developer to their aha moment as soon as possible without getting blocked. You know what a bad developer experience is, is just a ton of paper cuts where you're getting blocked all the time. Um, you're trying to achieve a goal. You usually have a goal in mind. "I wanna build a to-do app." And, um, you just get stuck on, on three or four things, and then you give up. So a good developer experience is take any one of those, whatever their goal is, and the ability to get them to that point as soon as possible.
4. BBBrett Berson
  What did you do in building the product or from a product strategy perspective to solve the graduation problem? Where, you know, I think a lot of people's early critique would be, "Oh, Supabase, great to hack on the weekends and get going." But when you're doing real in production workloads at scale, you're eventually gonna move away, and you guys have managed to keep just incredible customers at incredible scale. Did you
23:10 – 24:58
Solving the "graduation problem" Firebase never could
1. BBBrett Berson
  think a lot about that, or did you just make the product better and better? Or what was true about what you did where Firebase, obviously, that was a critique for a long time, which is a great place to get started, but not a great place to scale.
2. PCPaul Copplestone
  Yeah, we thought a lot about this, and it's actually kind of right from the start part of our strategy. So we want to build a generational database company. We had seen many database companies come at it and say, "I'm going to build a bigger, better whatever, and then people will wanna use us." And they didn't really succeed. If you look back over the past twenty years, probably the only database companies that have really managed to do well are Firebase and Mongo, and they did well because they targeted these day zero workloads that you kind of would choose them before you even knew what you were going to build back when you were a developer. So we knew if we wanted to build that bigger, better experience, we first had to win the day zero experience like the Mongos and the Firebases. So that's where the positioning open source Firebase alternative came from, where we just pushed that quite hard because we knew that people were choosing Firebase at the start. Well, let's give them another option. And then we smuggled Postgres in. A lot of- At the start, we didn't promote too much that it was Postgres. We weren't sure if people would understand it necessarily, why we were doing that, or they might even say, "I don't want Postgres, I want MySQL." At the time, it was more popular. Over time, it became clear that Postgres was, was winning, and so we slowly started to migrate our tagline from open source Firebase alternative to just this build in a weekend, scale to millions. And, um, the positioning helped that slow positioning, and we started doing a lot of our marketing is largely around memes, a lot of Postgres memes, uh, just talking about Postgres, promoting Postgres, doing what we could
24:58 – 26:10
The role of open source in Supabase's success
1. PCPaul Copplestone
  to, to promote it to, to developers, and sticking up for Postgres where, where we could in, in the ecosystem, and defending it for the different things and, and leaning into its features as, as much as possible.
2. BBBrett Berson
  What is the, the role of open source in the company's history, and how has that been such a input driver to the success of the company?
3. PCPaul Copplestone
  So everything we develop is open source. We have either a MIT, Apache 2, or Postgres license, with the exception of, like, the platform code or the billing and everything like that. But if you want a Supabase stack, you just can do dock compose up, and you get the Supabase experience. We don't put any tracking on that. If you wanna use it, you get it for free. Um, we try to stack it with as many features as possible. If features aren't there, it's just because we haven't quite got around to it, and we-- sometimes things move faster. So there's no real strategy like, oh, we'll use it as an onboarding tool to get people on, and we'll gate some features. It's really just because Ant and I are philosophically aligned with open source, and I love open source. Uh, Postgres itself is open source, um, so we get a lot from it, and we wanna as well contribute back to the ecosystem
26:10 – 35:24
The three distinct AI tailwinds: From pgvector to Claude Code
1. PCPaul Copplestone
  as much as possible. It means that we can employ a bunch of open source maintainers from around the world, and that's nice as well. We hope that we can employ more and more open source maintainers, which I, I think is really just good for the world.
2. BBBrett Berson
  Would love you to talk more about the incredible AI tailwind that emerged for the business. What was the story behind what it was like on the inside? Because you obviously built the company, were having a lot of success before everybody started vibe coding and DIY-ing.
3. PCPaul Copplestone
  Yeah.
4. BBBrett Berson
  And it seems like it just created just incredibly explosive growth. And then did it cause you to rethink the roadmap and direction, or maybe you could talk a little bit about that experience kind of re-accelerating years into building the company.
5. PCPaul Copplestone
  I see it in three distinct phases. So phase one was the kinda everyone was getting into embeddings on the database side, uh, vectors and embeddings. So we were one of the first to offer pgvector. In fact, I think we were the first. And, um, helping to promote that, we put that out, and that saw, um, a lot of, uh, uptick as well. End of twenty twenty-four was when the likes of Bolt and Lovable launched, and that was also an interesting... That was kind of the second tailwind. We thought we were getting DDOS'd at the time, actually, because we just saw this customer launching lots and lots of databases, or these two customers.
6. BBBrett Berson
  And they chose when they launched to have you all as the sort of standard, "Hey, do you just wanna set up a Supabase instance?"
7. PCPaul Copplestone
  Yeah. The experience would be you'd come in, you click a connect to Supabase, and it would bring back your, your database credentials, so then you could build on top of it, and you just prompt your way through a, through a back end. It's gone through several iterations, but yeah, I mean, the growth was very strong immediately. And you know, it's always vague. I mean, in hindsight you think, "Oh, it's very clear this is the right move. We should definitely support all these platforms." But I remember at the time, even internally, people were saying, "Ah, these are just prototypes, vibe coding." Lots of slop back then. Lots of slop now, um, sometimes, but I mean, good products and, and bad products being built. The thing that was clear for us was that principle that we had at the start. We wanna be there when people are getting started and then make sure that they want, never wanna leave. So even if they were getting started building things that weren't going to be huge businesses, we still needed to be in that space to, to learn, to understand. And as well, uh, I mean, a lot of thinking, oh, you know, do we need our own front end? But we kept, you know, we're clear that we just wanna be a database company. This is all we wanna do. So that kind of helped to hone what we should be in that wave, which was just this platform that will supply the back end for all of these AI builders, and that became the, the focus of twenty twenty-five, and we built out this product called Supabase for Platforms. It kind of looks like an enterprise offering, where an enterprise might need a single pane of glass to see all their databases and which ones are secure and tools around them and usage and everything. So this was the thing that helped us. We knew that we could kind of map this, this product that we're building for platforms. It was kind of mapping, um, to our enterprise roadmap anyway, but, you know, on different sequencing and a slight twist. So we just got to work building that product, and uh, it was a huge growth lever for, for twenty twenty-five. And then phase three is largely from, from January this year, the likes of Claude Code and Codex and everything that are just ramping up really, really fast. And these are the tools that are using more of the CLI, uh, MCP type workload, and we're seeing huge adoption from them. In, in fact, acceleration the likes of what we saw even at YC, but now happening off a base of, um, seven, eight million developers.
8. BBBrett Berson
  So is it just year after year, it feels like there's just so much more that you need to do than you can get done at any given point in time, and it just feels quite chaotic even at this scale?
9. PCPaul Copplestone
  Pretty much, yeah. So like now, of course, the... I mean, at these scales that you start getting to, then you've got these, like, success problems, um, which is just keeping up with the growth really, uh, and strange things like- In certain areas, we're going to run out of IP addresses in four months or something like that, and you've got to quickly solve all these problems, otherwise the whole business can't launch another database. You know, lots of things that just crop up that you have to swat away all the time, and they take a lot of focus away from that product marketing, like launch, launch, launch. But that's just the phase that we're in, I think. You see it with all the AI companies now, where you're either launching a lot or your stability is, is not so high. And so from our point of view now, we're just making sure that we can scale to the next, you know, uh, 10, 100 million developers.
10. BBBrett Berson
  If you break apart the company's life into a few chapters, how has your time spent changed in any given week?
11. PCPaul Copplestone
  Yeah, chapter one was pretty clear. Um, I was just building. Um, and that's a lot of fun [laughs] because as well, there's nothing more fun than building for people who want what you're building. We spent a lot of time doing, doing that iteration. When we got to around probably 50 people, we start splitting into, into teams, and I was maybe doing a bit of a hybrid of managing people.
12. BBBrett Berson
  But weren't you doing a tremendous amount of recruiting then if you had 50 people, or no?
13. PCPaul Copplestone
  We've never really had problems recruiting. I think this... We've got so many reasons to work at Supabase. The brand is well-loved. It's open source. It's developer tools. We're fully distributed. So a lot of the time we're finding people who, they were either building a tool that we needed or they were contributing to our, um, repositories, and we could see that they were doing a phenomenal job, and we just said, "Uh, do you want a job?" Or a lot of ex-founders actually were just coming to us asking to, to work at Supabase, so I don't think we were doing a ton of outbound, if I'm, if I'm honest. But eventually, that became more of a thing, and my co-founder is very good at that, and he, he is very keen on keeping the culture very, um, distinct as well. So we shared that between the two of us and, um, we're both developers, so we know what we want in terms of the, the culture of the company. Yeah, so recruiting became a, a big thing probably more last year. We, we had in the early stages, you know, I said at the start, I had kind of this, these scars from blitzscaling, um, without product market fit. And we had this idea that we'd only hire when we had a hair-on-fire problem for the first probably four or five years. And so we got to maybe 200 people with that mentality, or 150 people with that mentality, and then we quickly had to change. Um, like halfway through last year, we just said, "All right, there's just way more work than anyone can do, so we just need to get people, get people in as fast as possible." And then, yeah, it really became a, a hiring, hiring became a top priority, not just for us, but for all of the, all of the team.
14. BBBrett Berson
  Do you think given how much technology is changing, it's productive to spend time thinking about a three-year time horizon?
15. PCPaul Copplestone
  Yes, in some ways. I don't think you need to think about exactly what products to push out. Like, we don't need to think about exactly what product to push out. But we need to think how our platform will evolve. So a good example is when we started, the company was very dashboard first. Developers would come in, they'd launch the database from the da- dashboard, they'd use it. Now with agents, they're becoming very CLI first, and so this one's kind of obvious to, to everyone. But, you know, what spills out the other side of this is, okay, what that means is that everything is very code first, it's very Git first. And so what we want is, you know, on the CLI, for example, one thing that I, I want the whole thing to shift towards is that if you use the CLI, you get this Supabase folder, and that should be a pure representation of everything that's on your platform. So in code, essentially infrastructure as code inside your data- um, your folder, and that should include your, your database schema, declarative schemas. Everything should be there for the agent to understand. It shouldn't have to reach out to the platform. So what this means is that we just get parity across every surface area as, uh, that we can. Dashboard, CLI, MCP, all of them should kind of match. Then what spills out the other side of that? Okay, well, people want to branch on Git, so everything needs to be branchable, whether it's buckets for images, um, your database needs to be branchable. You need to, uh, have testing environments that are, that are very cheap and ephemeral for, for doing these branches. And then, of course, like there's the obvious stuff. If agents are, are building now, then they'll probably be operating in the future. So at the moment, maybe a developer's in looking at things, whether, um, the database is healthy or not. But of course, they probably don't want to be doing that, and that's actually where most developers don't want to spend any of their time, is looking at whether things are healthy or not. So building out the infrastructure that will have kind of self-driving databases on all vectors. The performance could be improved, the reliability,
35:24 – 42:58
Supabase’s egoless, hyper-competitive open-source culture
1. PCPaul Copplestone
  um, the security of it can all be improved by agents essentially, and then you can choose where you want to be inserted in- into the agentic flow.
2. BBBrett Berson
  What is distinctive about the Supabase culture, and why have you chosen it to be that way?
3. PCPaul Copplestone
  We're completely distributed and asynchronous. We chose this one largely because of... It's a bit of path dependency. We started during COVID, and then out of that, we continued on this way.
4. BBBrett Berson
  Do you think if COVID didn't happen, you would be a traditional in-office company?
5. PCPaul Copplestone
  I think we would've been forced to through YC. They really want you to come to SF and be based here and build here, and that is the right approach, I think, for 99.9% of the companies. I think for us it's worked well because we're open source. We hire a lot of database people, and those people are spread out around the world, so it's, it's worked well. Yeah. And now it's a bit of a superpower because our attrition is extremely low. But the leaning into the async, um, culture has helped because everything's written, everything's recorded, everything's Captured in Slack or Notion or one of our sales meetings is ingested into our warehouses, and this kind of solves the Metcalfe law, uh, issue as we scale up. So because everything's there ready to be searchable, uh, AI has solved this for us. Instead of our CFO coming to me and saying, "Hey, when is Multigres going to launch?" Then I can say, "Oh, you can just ask the AI the timelines," and he can, he can do it without reaching out to a developer. And him being non-technical, he might not even understand all of the intricacies of a product, and he can ask the, the AI, "Oh, can you explain it to me from a finance point of view? What does it mean?" And so, you know, this, this body of knowledge, the whole history of Supabase, has now been embedded, and you can search through it. And I, I think that's going to be a critical thing as we continue to scale up.
6. BBBrett Berson
  What about distinctive in the sense of how you behave, who is a great fit for Supabase and who isn't? What behaviors are celebrated? What gets someone exited? Like, how did you land on those type of distinctive things?
7. PCPaul Copplestone
  First of all, of course, learned very early that not everyone are built for async, and you have to be of a certain ilk to really love it. And if you didn't love it, you just weren't going to love Supabase. So that's the, that's the trade-off. I mean, you, you just have to be clear about that with people, and you'll miss out on some people who just could be good, but they won't work at your company. The other thing that is really important to us is we have quite an egoless culture, um, which often people think, like, means unambitious or something like that. But actually, uh, like Supabase is hypercompetitive. It boils down to the open source mentality, uh, especially like old school, uh, open source people who, you know, you're out there probably grinding in public, putting out your code for free, but you want it to be top-notch. You know, that's a certain mindset. It's hard to explain, uh, and hard to find, but you can definitely find it in the open source ecosystem. So we've tried to really capture that ethos inside our company as well.
8. BBBrett Berson
  How do you figure out if somebody has that before they join?
9. PCPaul Copplestone
  You know, you can talk about in the past, the projects they've worked on, problems, conflicts that they'd had, how they dealt with them, even knowing how they talk about things inside the interview. Is it lots of me, me, me? Is it the team and putting the team first and things that we worked on? Yeah, there's lots of little, little tells, I guess.
10. BBBrett Berson
  You think it's relatively easy?
11. PCPaul Copplestone
  Well, especially for my co-founder. He's the, he's the key bar raiser, and he can-
12. BBBrett Berson
  Suss it out
13. PCPaul Copplestone
  ... he can suss it out very well. Yeah.
14. BBBrett Berson
  Why is that so important to you?
15. PCPaul Copplestone
  I could be doing this business for 30 more years, you know, uh, and I wanna work with people like that. I don't wanna work with assholes.
16. BBBrett Berson
  There seems to be this, um, kind of warm, kind quality about you in my conversation with you. Do you feel like that is who you are?
17. PCPaul Copplestone
  I guess so. I mean, if you feel it, then, uh, yeah.
18. BBBrett Berson
  Well, there could be a whole different side of you. I mean, the thread I'm pulling on is I find that, you know, a lot of conventionally successful and ambitious CEOs are, like, very difficult, oftentimes cruel at times, and I don't... I'm not experiencing that in our interaction.
19. PCPaul Copplestone
  Yeah.
20. BBBrett Berson
  Maybe you actually are that. Do you... You know, maybe it's some of that New Zealand-
21. PCPaul Copplestone
  Yeah, yeah, yeah
22. BBBrett Berson
  ... sort of generous spirit. Do you think a lot about that at all in the context of, like, your identity as a CEO? Like, you're building one of the most spectacular infrastructure companies. There's a certain kind of kindness about you that comes through.
23. PCPaul Copplestone
  Yeah. I think probably, as you point out, because I'm, uh, from New Zealand, that we're generally thought of as a kind population. A lot of CEOs I know are definitely, as you say, they can be cruel or Machiavellian or something like this.
24. BBBrett Berson
  Right.
25. PCPaul Copplestone
  I... And I see that, I mean, even with the CEOs that I interact with or in the space that we're in, um, there's a lot of that. I don't think, uh, we need to be like that. Uh, like, uh, I'm very much a rising tide will raise all ships. The database space is gonna grow phenomenally for everyone. You know, I, I wanna look back at the end of my life and think, "Oh, not only did I build a big fucking company, but I also did it my way," and, like, people... ways that people will look back and say, "Oh, that's actually respectful," like. And I have a certain affinity to, especially in, like, the, uh, I've actually been doing tech for a long time. You know, the old school open source mentality where people are just out there building things and putting their code there and contributing and-
26. BBBrett Berson
  'Cause they love it.
27. PCPaul Copplestone
  Yeah, 'cause they love it, and, and I love what we're building, and I love the space. I love seeing what people are building. Like, I've got no qualms with anyone operating their way, but inside, like, the realm, the sphere that I'm operating in, I just wanna operate like a good human and, uh, see good, other good humans succeed.
28. BBBrett Berson
  And so do you think ultimately your... the culture is just a reflection of, of you, too, and your values and who you wanna work with and-
29. PCPaul Copplestone
  Yeah, I think it comes down a lot to that. And of course, then you hire a couple of people who are like that as well, who are-
30. BBBrett Berson
  It self-perpetuates.
42:58 – 48:37
A tactical playbook for raising capital
1. PCPaul Copplestone
  with each other, and they can't coexist.
2. BBBrett Berson
  Mm.
3. PCPaul Copplestone
  But, um, that's the thing that I, I think is untrue. Uh, it got pushed a lot by our investors, and I just said, "No, no, no, this is not true. This is how it's going to be."
4. BBBrett Berson
  You just mentioned investors. You talked at the beginning about fundraising. If you had to teach somebody how to be excellent in raising capital, what's like the little course that you would run?
5. PCPaul Copplestone
  Oh, a little playbook.
6. BBBrett Berson
  Other than the most obvious thing is build a spectacular business-
7. PCPaul Copplestone
  Yeah, that's-
8. BBBrett Berson
  ... that investors are-
9. PCPaul Copplestone
  Yeah, yeah
10. BBBrett Berson
  ... are tripping over themselves.
11. PCPaul Copplestone
  That's rule number one. If I was to do a tactical playbook, it's probably like, first of all, you need to be in touch with a lot of investors, otherwise you don't have any of your lead gen. So I'd probably, um, start meeting a lot of investors. A-and you really treat it like a completely different play from, from startups. You switch mentality from builder to, to, to fundraiser.
12. BBBrett Berson
  What does that mean?
13. PCPaul Copplestone
  I will normally, especially talking to developers, underplay a lot of what we're doing. But with developers, that hedging is to your detriment. In fact, they'll discount anything you say anyway. So if you tell them, "Oh, you know, we're gonna be a, a billion-dollar company," they'll probably think, "Well, oh, we'll only be a $500 million company." You say, "10 billion." They'll probably think, "Oh, only a billion-dollar company," you know? So whereas with a developer, I'll always, um, underpromise and overdeliver.
14. BBBrett Berson
  What do you think makes a great pitch? Or when you're telling your story, or you're having a catch-up with someone at coffee-
15. PCPaul Copplestone
  Mm
16. BBBrett Berson
  ... and you want them excited about the Supabase story, what is different about that than when you're talking to customers or people that you may recruit, other than maybe what you said, which is you have to be maximally ambitious because of the sort of discount that an investor might apply in their own brain?
17. PCPaul Copplestone
  Believing that you are going to be that ambitious is actually the thing that matters, and then sequencing of it. So it's a bit ridiculous to be ambitious and think that you're gonna get there anytime soon. But where we are today and where we want to get to is going to take, you know, 10, 30 years, and being deliberate about how we're going to get there and, and having clarity about the steps to get there is kind of what matters to an investor. So they need to both believe that ambitiousness is true and that I or whoever it is pitching has thought about how to get there.
18. BBBrett Berson
  Do you enjoy raising capital?
19. PCPaul Copplestone
  Yeah, not really at all, actually. It's a huge distraction from, from what really matters. But for a database company, it's a very necessary part.
20. BBBrett Berson
  Over the life of the company, it seems like you've been very PLG focused, kind of, at least in the early days, didn't get pulled into mega enterprise with an endless roadmap. And obviously, more recently, you have companies of almost all scales building on top of Supabase. Did you think much about when you would really think about a Global 10,000 company using the product and what they needed? Was that sequenced in a specific way, or did you just wake up one day and say, "Okay, we're a big company now. We can take something like that on"?
21. PCPaul Copplestone
  No, the sequencing was important. So if you think of types of companies from like risk-averse, um, enterprise, which will be not even just enterprise like bank or something like that-
22. BBBrett Berson
  Yeah, mega enterprise or-
23. PCPaul Copplestone
  And then like indie developer right down here, and then like a bunch of, um, like getting started use cases. So like launching their bank is, is like up here, production workloads. We started down the bottom left, and I think the big problem is that most people try to then jump. If they're doing PLG, they try to jump as well to the top right. Whereas we just thought of like adding these layers, so we're just building out. Even today, of course, we couldn't, uh, host a, a bank on our, on our platform. But, you know, I've got no doubt we'll get there one day, and it's just about making sure that we're adding those layers, uh, incrementally. So an enterprise actually could come in, um, be one of those players, and as long as it's one of those workloads that fit within the, the sphere that we are currently operating in, then we're happy to work with them. Innovation workloads, for example, if they wanna get started, even if they're a, a bank, or maybe they're, they've got a big open source presence, and they actually wanna understand how they can use some of our open source tooling, we'll, we'll chat to them about it so that we're building the relationship with them.
24. BBBrett Berson
  But at any given point in time, your resource constraint, like your ambitions and the roadmap is multi-decades long, and you can only ship something, so many things in X period of time. How do you think about, do I wanna make what we're doing better? Am I willing to go up and sort of move out in sort of the visual that you represented?
25. PCPaul Copplestone
  Yeah, as you add more people, then the r-roadmap kind of like is very linear. Um, like it's small and linear when we are getting started 'cause we only had a few people, so adding products. But then you've gotta add all the operational stuff plus the products and get all the certifications. So you need to build out those, those teams over time. We just saw enterprises coming in, and they might say... Well, not even enterprises. It could've, at the start, it was an SMB, and they'd say, "We need this." And that type of thing to add w-whatever they needed might be, you know, only, say, three or four months on the roadmap. And so we knew that we could achieve it, and then we, we add it, and it's available then for all of the startups on, on our platform. Now, if an enterprise comes in and they say something that is also gonna benefit maybe 1,000 customers, then we'll add it. But if they say something
48:37 – 59:27
Product-led sales comped on incremental uplift only
1. PCPaul Copplestone
  that's bespoke to them, then of course we'll just end up saying no because we really want to make sure that everything we're building benefits a, a huge pool of customers at this stage.
2. BBBrett Berson
  What about on the go-to-market side? Has that evolved a lot?
3. PCPaul Copplestone
  Yes. Yes. Um, so we do have, uh, now as well an enterprise motion where they'll come in, and it's more like a sales-led growth. But, you know, in terms of the sales team, their focus on that, it's very much like a 10% of focus, 20% of focus. The key focus for us is moving from, from PLG, which is just purely organic, people sign up, put down their credit card, to a product-led sales motion. I, I don't know how, how, um, popular it is. I think it's not, uh, especially not the way we do it. What we have done is take a lot of signals from our PLG motion. It could be like, for example, um, someone is, um, you know, they're thrashing their disk on, on the database side, or like they're hitting CPU limits or something like this, so they're probably having encountering a problem. And we pick up a lot of these things. We call them triggers, product triggers. And then when we find one of those, if they fit some, some category, we actually do like a automatic, automated outreach to them, an email saying, "Oh, hey, look, looks like you're having this problem on your database. Do you wanna jump on a call with one of our team?" If they respond, then, um, we essentially can get this report, uh, from, from their, their usage, and we can see all the products that they're using, and, um, we can give it to one of our success team, our sales team, and, uh, say, "Here's all the things that they're having an issue with," and just go help them. So our sales actually just looks like support, and that's important. We actually don't really wanna sell to people. We wanna help them to grow if they, if they want. Then we take the cohort of people who respond, and we rank it against all those who don't respond. So we've got that, uh, kind of as a, as a, um, control group. And what we do is we measure those who don't respond, how much did their, um, their usage grow. And actually we know, like quarter over quarter, it's 25%, versus those who have chatted to a, to a success person, and that's 125%. So we can see the incremental uplift from those who are chatting to our, our support team, our, our sales team.
4. BBBrett Berson
  Is the sales team, uh, quota carrying?
5. PCPaul Copplestone
  Yeah, on the incremental uplift only, which I think is the big difference from what, um, was traditionally done. You know, on a PLG motion, you could easily say, ah, get a salesperson and so on, like reach out to anyone and, and then you pay them on, on the revenue generated by that customer. But if that customer was going to pay you $100,000 without talking to a salesperson, then you don't really wanna be saying, "Oh, the salesperson could actually just be getting in the way." So we only measure, uh, and over time want to continue to measure that incremental uplift, and then that's what they get comped on.
6. BBBrett Berson
  Are they salespeople, or are they truly support or technical support or sales engineering style?
7. PCPaul Copplestone
  Sales engineering. Yeah, we've got a, we've got a mix of both, so, um, uh, account managers and salespeople and customer solution architects. And, um, the most important thing at our stage, especially going from a PLG, is very much like a, a, a very technical engineer who actually can understand the product, talk to the developer. If it's from maybe a firmographic point of view or someone who is more on the business side and they wanna say spin up thousands of databases, then it could be more of a salesperson, less technical.
8. BBBrett Berson
  In the process of helping that customer, are they selling them new products? "Hey, have you thought about using this?" Or, "We can help you with that," or...
9. PCPaul Copplestone
  They can do, but that's, you know... If they understand the workload and it seems relevant, then, then they can. But, you know, developers, um, not, um, they're quite allergic to sales, and so we definitely don't want anything to be forced down anyone's throat. So it's really the, the guiding principle is just be helpful to the customer, and, and that's all that matters.
10. BBBrett Berson
  When you zoom out and you think about the trajectory of the company thus far, are there any other unconventional or non-consensus decisions you've made or ways you've organized the company that have mattered a lot to the success of the company?
11. PCPaul Copplestone
  It's literally embedded in our product principles in the docs. We, we don't like lock-in. We try to build on protocols and open standards, so if you ever have an issue, you can kind of, like with our Postgres, pg_dump and take it somewhere else. It's your data. And this forces us to build a great experience and compete on that experience. To be honest, again, I don't know if this is a strategy that works. In fact, sometimes I see it doesn't work. Um, uh, and you never kind of really learn the counterfactual. I don't see many people online saying, "Oh, thank God Supabase have this principle, and now I'm gonna do everything with them." But for me, uh, I just know from, like if I was to use myself as a model of the customer that I wanna build for, I think that's just important from the ethos of, uh, how the platform should feel, that everything feels like simple primitives, protocols, and, and it can work without lock-in. And I think developers feel lock-in very early on in their investigation of a platform, and it, and it scares them away. It scares me away from things that I feel, uh, too locked in. So yeah. A-and it's hard for us as well because, of course, like when it comes to developer experience, I'd love to just do something that Postgres completely does not do to achieve some, some goals that we want from the product side. But it's hard for us to do it in the Postgres way. But if we can pull it off, then there's a certain elegance about it, like a craftsmanship that I think seeps through and, and maybe that's the one that I can point to. Um, I see online people pointing out how the elegance of the platform that, um- Is using these open protocols and primitives, but somehow makes it feel very integrated and like a single product
12. BBBrett Berson
  And that's sort of what's really guided these decisions?
13. PCPaul Copplestone
  Yeah. Yeah. Very much so.
14. BBBrett Berson
  What have you found to be very hard? Have there been these intense pivotal moments? It feels like so much of it has been immense amount of work, but not like soul-crushing or near-death experiences, or... There's a calmness about what's happened with the company you've built. I don't know if you-- how you would articulate it. But sort of in the rear view, have there been, been these intense crossroad moments, these very hard, tricky things, or has it just kind of felt very natural and kind of just flowed out?
15. PCPaul Copplestone
  No, I think like... I mean, it's hard to emphasize how painful it can be for a lot of people scaling. [chuckles] Like, this is a success problem, but scaling for some people, like, uh, myself included in the early days, meant like, you know, grinding very- for very l- long hours. And yeah, I mean, we've got some, some people in the company who are going through periods and, you know, get burned out because there's just so much to, to do. Because a- as I said, we had this hiring philosophy that didn't allow them to offload, and then you get this hero culture internally where they're the only ones can-- that can solve it. But that's very hard to solve because the only people that can solve a hero culture is the heroes themselves. They have to hire those people and train them up and offload a bunch of stuff. So this is kind of like a mini thing where, like, my painful experience was giving away my Lego and all the things that I kind of wanted to do, and they as well have to learn to do that themselves, even though they might just be an engineer and they don't think about having to do that. They don't get people telling them all the time, "This is how you escape a hero culture." So a lot of the hard periods is just hitting these scaling dynamics, and that can lead to all sorts of issues. I mean, whether it's like running out of capacity on, as I said, the IP addresses or literally just servers capacity and things like this. And these things are very hard to deal with because they're kind of like unsolvable in, in many ways, and we have to scramble to do all sorts of things. But you want to make sure that you're doing your best for your, for your customers and for a customer-centric company to not be able to do an amazing job in some areas. That's what I take painfully, yeah.
16. BBBrett Berson
  What about you has made the company work? Like, you've been, to date, immensely successful as the founder and CEO of this business. And so, like, what about you or your temperament, skills, abilities do you think is, like, the input driver?
17. PCPaul Copplestone
  I think the main thing that matters is I think in processes. So I, I think a lot of people think in outputs or, like, fixed points and things like that, and I very rarely think this way. It's more... We have a term which comes from the Toyota production system that we use a lot, which is called kaizen. Kaizen means to incrementally improve on things from the CEO to the assembly line worker. So, um, in the Toyota production system, they literally mean down to the cleaner will look for perfection in how they clean and doing it as a system. So I love this way of operating and thinking of things always like, well, things go up, things go down. They're, they're just processes. How much they go up and down is what we need to matter. There are control targets on, on all of these things. So, you know, I largely for a long time thought in kaizen and, and used that a lot, uh, internally. So from the product side, just increment the product, make small improvements, ship and shout to the business itself. We've got processes. The RFC process is broken. Let's change it. Just make a small change and, and never trying to make anything a big bang change. It's always just incremental. Then from there, if you can map your business into processes, so that's where we're kind of at, at the stage, which are more isolated. You can look at, you know, your top of funnel and that's isolated maybe to the marketing team or the dev rel team. And you might look at your, your churn as a process, and that could be isolated to the product itself. And then largely, you know, towards the tail end of this, you are even now starting to think more in systems, so going up a level again. And the system is from
59:27 – 1:02:51
The production philosophy behind Supabase’s operations
1. PCPaul Copplestone
  what end to end does it matter? You know, it's no good, for example, automating some small part of the business. What actually matters is making sure that a full end-to-end part of the business can be completely automated. So that includes the system of, um, especially as we've grown now into multiple teams, product team, engineering team, design. How do these three teams operate as a single unit from one end of the spectrum to another? And the kind of handoff between the teams then becomes what, what is the most important thing? Anyone can iterate really fast in a small ecosystem as like a startup does. But as you grow, what matters most is having these improvement cycles within the entire system.
2. BBBrett Berson
  Talk more about why you think this way of seeing the world has mattered so much for the company.
3. PCPaul Copplestone
  I think because people unblock themselves a lot. If I always scope things down to being small improvement, small improvement. You always see people getting blocked on the big things. They'll try to do something really ambitious, and, uh, it'll... It's obvious why it happens. I call them, like we do RFCs, requests for comments, uh, which are kind of like our PRDs. The design team might put something out, and I might like a hundred things inside what they've done if it's a huge thing, and I might dislike that one thing, and I just comment on that one thing that I dislike, you know? So it's, it's obvious where things get blocked. You wanna have small changes which can easily get through the systems of blockers. Avoiding the blockers and giving people a mentality to avoid those blockers so that they continue to ship is, is important. And then enabling other leaders in the company to remove those blockers if necessary is also a critical part. So defrag, we call it in, in Supabases from the product side, but also from the, from the business side. Uh, we went through a cycle of looking at all the systems that kind of are a bit broken and like a defrag, the old defrag in, in, uh, computers, like tightening these up- those up.
4. BBBrett Berson
  So I just wanted to wrap up with what is it that you want your customers to say about you and your team members when you're not around?
5. PCPaul Copplestone
  Me personally?
6. BBBrett Berson
  Yeah. What's like the North Star for you?
7. PCPaul Copplestone
  For my team, I would hope that they don't say much about me. I would hope that they think we did it, you know? That's more important to me than like, "Oh, Copplestone was in, and he like, he's such a good leader," or something like that. I would far rather them feel like, "Oh, we're smashing it," you know? So that's way, way more important to me than anything that they would say. From the customer point of view, I think the thing that I would want them to think, I, I don't need them to say anything about me, but to think that I actually want to solve their problems. That's pretty much it. And like to feel that, you know, I'm in the community with them. I'm like them. That's how I feel, like I'm just a builder as well. And I'm in there just to fix some hard problems and, and, you know, over time, I would hope that I'm building the platform that they kind of want to see in the world.
8. BBBrett Berson
  Cool. Thank you so much for doing this.
9. PCPaul Copplestone
  Thank you.
10. BBBrett Berson
  I really appreciate it.
11. PCPaul Copplestone
  Yeah, great.
12. BBBrett Berson
  This was great. [outro jingle]