Paul Copplestone on Building for Builders

Felicis hosts a conversation with Paul Copplestone, CEO and co-founder of Supabase (opens in new tab).

Paul, a two-time founder, always wanted to start a dev tools company, and Supabase is the beloved database platform that helps developers build in a weekend and scale to millions. This conversation touches on how Supabase built its product, enhanced its positioning, and how the team encourages a remote culture that ships constantly and has attracted dozens of former founders.

Timestamps:

00:00 Intro

02:00 Why Paul started Supabase

03:30 Supabase’s distributed culture

07:30 Building and maintaining company culture

12:45 Operating in the AI space right now

20:00 Product approach at Supabase

21:40 Positioning the product against competitors

25:00 Early challenges and team focus

27:50 Working with enterprise customers

29:25 How Supabase does launch weeks

30:54 How Supabase is structured like an open-source project

38:19 Advice to entrepreneurs

‍

Transcript

Note: This transcript was automatically generated and edited for clarity, some errors may appear.

Viviana Faga: Thank you so much for being here, Copple, it's great to see you. For those of you that don't know Supabase, Supabase is an open-source database platform that developers use to build their projects quickly and scale to billions. Over 40 percent of the recent Y Combinator batch built their products on Supabase, and over 5,000 databases are launched daily. The Supabase GitHub repo has over 74,000 stars, which ranks it in the top 120 of all-time GitHub repos. This is pretty incredible because the company is only a couple of years old. How many years now? Five?

Paul Copplestone: No, we're four. Yeah.

Viviana Faga: Four. Yeah. See, I was getting ahead of myself. Coming up on five. Copple is the CEO and co-founder of Supabase. Thank you for joining us.

Paul Copplestone: Thanks for having me.

Viviana Faga: So let's move into building Supabase and what it took. Before Supabase, you started two companies. What inspired you to start Supabase as your third company, and what initial problem were you aiming to solve in the developer community?

Paul Copplestone: Yeah. First of all, I always wanted to do a DevTools startup. My previous two were not in the DevTools space, and specifically, I always wanted to do a database startup. That was in the back of my mind. Then, in my second startup, I was building using Firebase. Firebase has this very cool thing where it can listen to real-time updates from the database as you make changes.

We were using it, but unfortunately, it wasn't scaling very well for us, so I had to migrate to our Postgres database. Postgres doesn't have the real-time feature, so I built that, I open-sourced it, and it started getting traction. From there, I just decided that was good timing for me to do this database startup that I had always dreamed of.

Viviana Faga: That's great. So it really was out of necessity and need, and building for the developer community. That's awesome.

Paul Copplestone: Yeah, we'll go with that, but I think this is the one that I wanted to do all along.

Viviana Faga: All right. So you've built an intentional culture at Supabase. We talk about this a lot, interestingly enough, at the board meetings because I think it is so unique and has developed what we've termed a great team.

Talent market fit: what traits and behaviors have you fostered that have attracted the talent and team you've assembled? It's definitely an Avengers team, I like to say, including dozens of former founders. I think you hear about this in the Valley; some companies, very few, are formed with this at the outset, but you were very intentional in building with former founders. So I'd love for you to just unpack the culture behind the company.

Paul Copplestone: Supabase is quite flat. We have a lot of products with an entire back end as a server. It means that we've got quite a few products all building on top of a common substrate that is Postgres. But really, the thing that we wanted was almost like an open community.

We're fully open-source, so it has to be quite distributed. Very autonomous. We wanted to make sure that people have a developer mindset. They're very curious, they're very hardworking, and they have a lot of intellectual honesty, and that's how we built the culture. Former founders fit really well into Supabase because they fit into this distributed culture where we can give them a lot of autonomy and leave them to it. Then we don't have to check in every day to see how they're going. They understand what needs to be done without us getting involved day-to-day.

Viviana Faga: Part of this culture that I think is so unique is you get the question of, "What do you do about in-person time?" or "Aren't you missing that?" because the company is built remote-first. You guys are very public about this. There's actually a great blog post on it that I don't know if it was you or not that published it, but it's a really fantastic read. Talk to me a little bit about those launch weeks and how they fit into this whole culture.

Paul Copplestone: Yeah. So the launch weeks themselves are a different piece, but getting to the culture piece, I guess the way it works is we don't really tell people what to do. They tell us what they're doing based on the feedback that they get from the community and from our priority customers. We'll just try to make sure that there are some important tasks getting done at any one time. And then we work towards shared timelines that happen to be launch weeks. So maybe three times a year, we do these major events where people come and say, "Hey, this is what I'm shipping for launch week."

We say, "Great. Here's how we'll package it." And that's how it works. The good thing about ex-founders is, you know, we want to leave them to their own devices. They're probably ex-founders. If there's a reason why they're ex-founders, they've probably spent the past three years grinding, trying to find product-market fit, talking to customers. These are all the traits that you really want from a good product engineer. And then they join Supabase, and we're lucky enough to have some product-market fit so they can really appreciate the fact that they've got a ton of customers giving them feedback on what to build. And they can put their head down and they don't have to worry about all the schlep.

They just leave that to me and Ant to do all the kind of business-y stuff around it. And they get to focus on the fun part: building things that developers will actually end up using. So they just fit in really well, usually from the outset.

Viviana Faga: I think it's wild that as you're growing bigger, you don't see yourselves ever wanting KPIs. You think about the old way of building companies and performance reviews, and I think if you hire a bunch of really talented people and trust them when they're so hungry—to your point on just getting that feedback—that's very unique. You might never have to employ that. Who knows if you're a couple thousand employees, that might change, but at least for now, it really doesn't agree with you and what you're building.

Paul Copplestone: I think there's a time and place for everything, probably KPIs. I don't know if we'll ever be the type of culture that does OKRs and gets really low down, but we want product KPIs, and if the product KPIs are working well, then we know that the team is doing something right. And, where we don't want to go is too strict. We basically set up our organizations for principles. We have a very principle-based culture, and we tell people we don't want to micromanage; we just want to tell you how we want the org to function, and then you fit within those boundaries. Sometimes we shrink the boundaries; sometimes we expand them, depending on what's working and what's not. But yeah, it's a lot of work to do KPIs, and we don't want to have the type of people who require KPIs or full OKRs, at least at this stage of the company.

Viviana Faga: Yeah, that doesn't sound like fun. I don't think anyone likes that. Yeah, who wants that? It's funny, you see this in the Valley; folks are talking about this a little bit more. I think I wrote a post on this about a year ago. But one of the unique insights that I've noticed lately is that shipping speed is certainly becoming a moat for software companies, right?

Paul Copplestone: Yeah. I don't know if we need to reinforce it. The truth is that, actually, I think most developers want to ship fast. That's the thing, and if you lay the fertile ground for them, then they will embrace that as wholeheartedly as possible—sometimes a little bit too much, to be honest. So, really, it's often a case of not having to develop a culture of shipping speed; it's more making sure that you clear the blockers. One thing that's certainly important within our organization is this concept of Kaizen, which is from the Toyota production system.

It just means continuous improvement. And the thing here is a continuous incremental improvement. I think often it's hard to ship things inside organizations because those things become, like, the features become too big. We are very, very tight on making sure that the features that we ship are smaller and doing lots and lots of small increments, and they build up over time.

It probably looks like we ship big features on a heavy cadence, but the truth is that it's probably just the accumulation of many small features that we bundle up and call a big feature at the end of a quarter or something like that. For us, we built a platform around Postgres, and Postgres is very extensible.

So, in our worldview, everything is a feature of Postgres, and we've spent a lot of time building first-order primitives on top of Postgres. Now, what's happening is that we're releasing new products, and actually, they're just repackaging or modularizing those primitives so we can move quite fast. It's just usually a set of docs that are saying, "Use these three features together, and you get a new product." So we actually did that with two of our most popular launches in our previous launch week, just last week. Yeah, two of those new products were just features that kind of already existed, and we repackaged them.

Viviana Faga: That's great. Certainly, the community seems to certainly love it. Which leads to my next question. So before Supabase, it did feel like it was rare to see a developer-focused company that was, I would say, cool. Maybe there are a few out there, but I think Vercel is one, right? That certainly is cool. How did you craft this tone for the company, and how important has it been for community building?

Paul Copplestone: I don't think we're one of the only ones. It's definitely popular now. I don't know if we popularized it. And to be honest, we did not set out to be cool, per se.

I think, first and foremost, we just wanted to solve problems with databases. And then maybe our unique positioning just came around because we wanted to be different, to be recognized. We use a lot of memes. That was a happy accident. My co-founder, Ant, is very good at memes.

Viviana Faga: We used to call him the "meme lord" in the board meetings. And he loves it. He really spends time on it, which is great.

Paul Copplestone: Exactly. Yeah. He does a great job. And he's the CTO as well, so that's the funny thing. But yeah, it just emerged, I guess, this kind of way of doing marketing, and it worked. And again, just like our Kaizen approach to the product, anything that works, we double down on; anything that doesn't, we just forget about it and move on to the next thing.

Viviana Faga: Yeah. And you don't have to make a big deal about it. It just didn't work, but at least you tried it, which I love. Let's talk a little bit about the AI era and building in the AI era. Supabase powers some of the largest and most used AI apps and platforms, which a lot of people might not know. I think folks are a little bit surprised when they find that out. So I think Udio, LangChain, there are a couple of other companies. What are the needs of AI-native companies like these compared to traditional SaaS companies, and why are they choosing Supabase?

Paul Copplestone: Yeah, compared to the other SaaS, I think the thing that's similar is the growth rate of the user base is insane. We see a lot of these ones scale.

Some of them, I remember one of them scaled from zero to a million users in 10 days, I think it was. So it was just one of those astronomical growths. The thing that's quite different from maybe the SaaS is generally the founders are builders themselves—developers—which you might not think is important, but we center our platform for builders, and builders generally don't want to be sold to. So our kind of job with these AI-native companies or dev tool companies is really just to give them a good platform and get out of their way.

Just make sure that they're not blocked. Usually, they don't want to get on calls. They don't want to learn about all the options available. And they just want to... they know what they need to do. They need to put their head down and work. And so we need to make sure that we're covering all the bases, which I think the platform has done for several years now, which is why our timing was quite good.

By the time that the AI era came, we had a good amount of maturity around our platform and our feature set that they could actually just build without having to make too many requests. And largely these days, it's just maybe they don't know the ins and outs of the database, so they might do some things inefficiently, and we can just jump in and help them out if they need it.

Viviana Faga: What are some things you've been excited to build with AI, and where else are you excited to explore?

Paul Copplestone: AI for us so far, we've done some deeply integrated AI. We offer products for customers who are building with AI, and then we've done some experiments as well. So you can use an AI assistant in our dashboard.

And that kind of helps you to build your database, helps you set up your schema, helps you to do row-level security, all sorts of things. And that's been good. We just did another release this launch week. The nice thing about this was when we started Supabase, we started with Postgres, and at the time, actually, it wasn't very popular. The reason why is what we thought was because it was all SQL-based; developers didn't really like to write SQL. At the time, people were... and, for example, Firebase is a NoSQL database.

You can just throw documents in it. However, what's turned out to be the case—which is another really fortunate tailwind for us—is that LLMs and AI really love this kind of structured language because they're so unstructured themselves. So you can feed it a database schema, for example, and it's very structured. Then it can really understand the context of your database, and it can suggest some charts and tell you which query to run. You can't really do this with an unstructured database. So it just happened to be one of these really fortunate coincidences that, you know, we started with this model. We were building forms around it, trying to make it easy for developers. Then AI came along, and we stripped out all the forms and just turned it into a chatbot, basically, and so it's solved a few of our UX problems as well. We did some experiments on AI, so we've released a product called Postgres.new, but we've relabeled it to database.build. And you can build databases inside your browser using AI. This has been an experimentation phase; it's a little bit like V0 or Bolt.new, but specifically for the database. And this has been pretty interesting for us just to see how far developers, or which type of developer, is willing to use it, which turned out to be significantly different from the developers who are signing up for our site.

There was only a 30 percent overlap, I think, between customers who used Supabase.com and used database.build. There's a whole profile of developer coming in through another type of integration. These are the Bolt.news, the V0s, the Lovables. It's really a bit of a tailwind. And we're starting to see designers signing up for Supabase, using it, giving us very different feedback from what developers are giving us. And yeah, I think it's exciting. It unlocks, if you think that in the world there are a hundred million developers, "pure developers," as you might call them. The definition of "developer" is expanding a lot, or at least the definition of "builder" is expanding a lot. So it's exciting for us. Of course, it introduces some different UX challenges. How do we make sure that we can cater for many different types of profiles? But yeah, that's where the growth is going, and it's rapid and recognizable.

So it's pretty cool to see more people building. Anecdotally, I was visiting, or a friend came to visit me, actually quite a new friend. And he said, "I used your product for the first time." We didn't really talk about Supabase.com, and he said the first time, or the reason I used it, was because I've been building with Bolt.new. He's actually a writer by trade, and I said, "Oh, that's pretty cool. How was it?"

And he gave me some feedback. But the thing that I thought was really cool was after we were hanging out for the evening, he said, "I'm really addicted to building. I'm going to go home and just try and knock out a couple more hours with Bolt.new." And I remember that feeling myself as a developer where I would go and go back to coding and I'd start building something.

And it was really an addictive process because you're putting something out to the world. And it's quite cool to see a non-developer describing that exact same process himself without knowing how to code. And of course, he'll learn over time, I've got no doubt, but it's cool that the audience is becoming a lot broader for us.

Viviana Faga: That's fantastic. Yeah. I can't imagine when you created Supabase ever thinking, "Oh, writers are going to build." Yeah, I wouldn't have been in your target persona. That's incredible. But it is some of the feedback that I think you see when you talk to people about Supabase: it's very easy to get started. I think that's part of it. It's hard to keep things simple, right? I think that's something that's a fine balance over time, too.

Paul Copplestone: I think that's been our biggest challenge. We offer Postgres, right? So the key thing is trying to make sure this is a product principle and a platform principle. Winning in the database space historically has been very hard because you need to try to crack this very sticky, high-gravity tool.

Databases, people almost never migrate away from a database. So what people have generally tried to do is make things very scalable and convince them to migrate, or make them very simple and then you lose the depth; maybe it doesn't have the scalability. Our tricky balance has been trying to make things simple while making sure that you can scale up and you've got some scalability stages.

So right now, getting started is one of those things actually we need to make even easier for these non-developers. But we've catered for those who kind of graduate beyond just the ease-of-use tooling. They can start getting into database migrations. They can start using read replicas. They can do distributed clusters, all the things that they will need.

We know they'll need if they scale up. So that's the big challenge for us.

Viviana Faga: That's great. Let's pivot a little bit and talk about what you've learned about going to market and positioning against competitors. We have a lot of conversations about this, especially early on. How has your thinking evolved, and maybe what are your general thoughts on it? And potentially, maybe it's evolved over time.

Paul Copplestone: Yeah. So our early positioning was the "open-source Firebase alternative," and that worked very well for us. I remember actually—I don't know if we've had this conversation—but at the early stages, before we joined YC, we positioned ourselves as "real-time Postgres," because as I mentioned, that was the feature that I built at the start—real-time. So I thought it's getting traction, people will like it.

But we just weren't quite picking up. And so one day I changed the tagline to the "open-source Firebase alternative." That was the only change. So I put it on Hacker News. It went to the top of Hacker News, and from that point on, that was the positioning that worked. And it was quite funny because it really solidified in our brain: positioning is really important. No matter what you produce, how good it is, the way you market it is quite important. Of course, over time, as you grow, you want to become a standalone tool. So we don't always want to be an alternative to something.

And I do remember an analyst saying, "Ah, people say you'll have the graduation problem, maybe that Firebase has, and it doesn't scale very well. Aren't you worried that people will think the same?" And I wasn't too worried because I knew that it was just Postgres. But our positioning did have to evolve. And so over time, we just started seeding into our marketing, into our website, into our memes: "It's just Postgres. Supabase is just Postgres." And people started to understand, "Oh, if you can trust Postgres, you can also trust Supabase." And I'm sure over time we'll have to change that positioning yet again, as we move upmarket or change for a different type of audience. But I really don't think that you might be beholden a little bit to your early positioning, but I do think that you can correct it or shift it over two or three years.

Viviana Faga: That's great. And you didn't have to change the product at all. Isn't that wild? Where you just change the tagline or you change... It's always surprising to me because I'll have this conversation with founders when I always say, "Your home page is what you are." Right. People are trying to learn who you are, so the first place they go is to your website to learn a little bit more. And if you're not thoughtful about that property and what it says about you, it's really going to impact your business. And they're always surprised when I say, "You don't have to change a single thing about your product, but how you position it will impact who signs up, how it's used going forward." So that's great. You are actually the embodiment of that because a lot of people don't believe me. "Oh, people will just try it. They'll love it." And I'll say, "Nope, but they're not going to hit that sign-up button if the message doesn't resonate."

Paul Copplestone: It's true. So some conceptual way of knowing what they're signing up for was really critical for us.

Viviana Faga: Absolutely. So what was one of the challenges that you faced early on, and how did you overcome it?

Paul Copplestone: I think that's the thing. People just look at a snapshot in time and they forget a startup is a very long process. We're going to be at it for generations, right? Hopefully, if we do our job, that's the kind of long-term view. I wouldn't say anything has been... I think we've had a million challenges, but no challenge is insurmountable.

They just need to be chunked down. And our Kaizen approach to product is also our approach to the company. We chunk everything down. We look at it as small problems. We solve what we can, we forget about what we can't—these are the kind of mentalities that we have. And I think we've been very fortunate in hiring ex-founders because they typically have faced far more challenging things than what we've had at Supabase. Because what's more challenging than having your back against the wall? Your own company is about to die. You're running out of money, you've got mouths to feed. These things are like life-changing events. And to hire people who have faced those type of events, everything seems easier at Supabase in comparison.

Viviana Faga: Sure. Especially given the fact that you're probably working remote, right? And so you get to work when you want to work, on what you want to work. And that agency that you've given people is very unique and incredibly motivating.

Paul Copplestone: They're still going to work hard, and they do.

Viviana Faga: Actually, one of my funniest stories with Ant is, I was joking with Ant—Ant is Copple's co-founder—and I said, "Oh, you don't want to move to San Francisco like everybody else?" It was like, there was a big sort of push, maybe this was a year ago. And Ant laughed, and he said, "I would spend too much time at meetups and events and happy hours. I really want to live in like a boring place where all I do is work." And then I realized that's like everyone that works at Supabase is intentional about actually living in a remote place that is a sensibly nice, but probably a little bit boring, and that's by design.

Paul Copplestone: By design. I think we do have people in tier-one US cities, but for most of the builders, they definitely want to be somewhere quiet and focus most of the day.

Viviana Faga: Yeah, I think it makes a ton of sense. What has it been like working with enterprise customers such as GitHub, like GitHub Next? What's that experience been?

Paul Copplestone: Yeah, it's pretty cool. The cool thing about the enterprise customers is that they're also builders, from what I've noticed, and they get to contrast themselves with a new developer. An indie developer has a choice of any type of tool. An enterprise developer inside a big enterprise only has a small subset of tools that they can contrast you against.

So Supabase seems, when you compare it to, say, raw AWS or GCP or whatever else they're using, Azure, coming to Supabase is like a breath of fresh air. They love using the product as a result. So that's nice. They also—and this is the dynamic that I like—the developers are usually champions, and they can give me feedback and steer the direction of the roadmap.

So, and our success team as well. So that's nice. Having direct, very tangible feedback. We can ship it, put it in front of them, and they get excited as a result. Of course, the challenging thing is you've got to deal with the security reviews, the legal—these things take a year. But those are the ones that I leave to someone else.

Viviana Faga: There will be AI that solves that for us.

Paul Copplestone: Please, someone make it fast.

Viviana Faga: We talked, we touched on launch weeks. I think different companies do it different ways. I think yours is very unique. It's really special. Let's talk a little bit about that. What are they for you? How important are they? Where did they come from? How effective are they at driving awareness? What are your thoughts on launch weeks, and do you think others should incorporate them as well?

Paul Copplestone: Yeah, for us, launch weeks started, I think in 2020, after we finished YC. And the reason why was: at YC you have demo day.

And so you're building for three months, or you're working towards a deadline. And then after this three months, you have this event that you're shooting for. After you're done with demo day, you get out of YC, and everything feels daunting. There's no end in sight.

So all we did was we internally said, "Let's recreate this demo day-like event three months in the future." And we did that, and we shipped something big. And then when we were all getting together the day after shipping, we said, "Okay, how do we do it bigger?" And we decided, "Let's ship one thing every day for an entire week." We didn't actually think we would end up doing it because it seemed just too ambitious, but it ended up working. And in that first one, I think we saw our top-of-funnel traffic increased by 30%.

Paul Copplestone: Yep. So I guess there's the cultural part and the kind of technical part. Technical: how we structure things, the tools we use. Culturally speaking, yeah, I mentioned at the start that we hire or we build our organization a little bit like an open-source organization. And that's the profile of person we hire as well.

Quite autonomous, able to look after themselves. Very few meetings. Yeah, we give them a lot of autonomy. From a kind of cadence point of view, the way it works is we have lots and lots of small teams. Teams have, by requirement, one meeting a week, and then outside of that, they can attend any meeting, but they don't have to.

They can just do their one meeting and get back to work. They're like stand-ups where they just share what they're working on, or it's a time to chit-chat and get through some important tasks. Otherwise, almost everything is done asynchronously through a written culture.

We have many processes for this one, and usually they build organically. Now we have a lot; at the start, there weren't too many. But the tools we use are—we try to keep them very limited—Slack for synchronous comms, Notion for async, and Google Meet just for getting on meetings. GitHub as well for working with our community.

Then generally what we do is, if we are going to design a big project that we're going to work on, we build RFCs, Requests for Comments, so anyone can build an RFC. This could be like, "Hey, I want to push out a new product in Supabase," or "I want to develop this feature within the existing product." And they focus, first of all, on what problem they're solving, which customer they're building it for, and how they plan to solve it. But even this process has improved over time. For example, when we first started, you just put the problem and the solution. What we found was people had this thing that they wanted to build, and so they would write down the solution, and then they'd make up a problem. But this is, writing is a way of rethinking about problems, in my opinion. So what we made them do, instead of just listing a problem, you actually have to write—sorry, instead of listing one solution, you always have to write three solutions to the problem that you're trying to solve.

This kind of forces the developer to think about the problem that they're trying to solve. The other really important thing—and this is really critical—I said that at the start, one of the traits we try to look for is intellectual honesty. That's because when you... this is a human trait, every human has it, but when you come up with a solution to a problem, you become very wedded to that particular solution. And over time, especially in an async environment, you'll put that solution out there. The act of writing it down embeds you even deeper into the solution. Then 24 hours later, you get some comments from the rest of the team on your given solution, and you feel like there's too much distance, they're attacking your solution.

So to counteract that, this "come up with three solutions" was a really good way of decoupling the person from this one solution because they've presented three solutions. Then, actually, because of the way the human psyche works, you can decouple and you can think differently about the problem, and people can give more suggestions, and you're less likely to become defensive.

We've built this process over time, and it'll continue to change, no doubt. It's not perfect. But that's one of the mechanisms that we use for product development at Supabase. What else can I say? Yeah, there's a ton of things that we do in terms of just small practices. Every Monday, we do a thing called Monday Metric Madness, where all the teams share their key metrics, their key KPIs for their team, how many signups they have—all in one Google Sheet. The temptation actually is to automate this, where you can come up with a dashboard and you automate all of your metrics and you can look at them.

The problem with automating them is that the people building no longer look at the dashboard that is automated. So we actually have resisted the urge to automate any of these metrics. We tell them to come up with their own important metrics, and then we make them write it down every single week. And then inside that thread, they also share their team stand-up so that the rest of the teams can get a bit of a cross-functional view of what's happening inside the organization.

Viviana Faga: So is there a call on Monday where everybody reviews it?

Paul Copplestone: No. It's independent; you post it, people can read at their leisure.

Viviana Faga: Interesting.

Paul Copplestone: Just async. Yep. Everyone's... I think we're in 30. No, in terms of time zones, I think we're in 60-something time zones now. So it's just a very hard task to do, even company all-hands. We end up having to do two all-hands in a day, so we try to minimize the amount of face-time that people have to attend, and the async just works good.

Usually, for those type of initiatives, you don't need to know everything as a product owner. You might only need to know about maybe one or two adjacent products. And so skimming through these updates is quite a good way of doing it. Of course, you know how it is. An org grows. What we were at 30 is very different from what we're at a hundred.

Now we're starting to set up some cross-organizational initiatives or teams. So more of an operational, like product ops, and these are helping people to fill out their RFCs so they're more complete, more presentable to the rest of the teams. So the rest of the teams don't ask a ton of questions. They can just interface once with one person. Iron it out. Essentially, they're just quarterbacking the process for the product teams themselves. Things change within the organization, but it depends on the stage of the company itself.

Viviana Faga: That's great. Is there one question that I didn't ask you that would come back to you sharing some insight around company building if founders are looking at this video thinking, "How am I going to build something that is generational?" What is some of the advice that you would give them?

Paul Copplestone: Yeah, I think the YC culture is pretty clear on this one. You just listen to your customers, solve a pain point, and you work diligently on that all the time. There is some advice. There's a lot of cliché advice out there. Often it's, "You give up too fast on things."

I think that's an important one. We've had a lot of products that we push out, and they don't quite hit on day one, but they build over time, and then eventually, people love them. So yeah, it's hard to come up with any one thing, but generally listening to your customers solves for those problems. Either you get a hit immediately, or if you don't, you increment towards what your customer's feedback is, and you end up building something that they love over time. So yeah, using that as a mantra, at least I think that's what we've done very well at Supabase.

Viviana Faga: All wise words. Thank you so much for taking the time.

Paul Copplestone: Thank you, Viv.