Felicis hosts a conversation with Paul Copplestone, CEO and co-founder of Supabase.
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, which 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. So 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. And then in my second startup I was building using Firebase. And 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. And so I had to migrate to our Postgres database. And Postgres doesn't have the real time feature. So I built that, I open sourced it, it started getting traction. And from there, Yeah, 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 develop 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 like an 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 has to be quite distributed. Very autonomous we wanted to make sure that people have Kind of this 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 distributor culture where we can give them a lot of autonomy and leave them to it and 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, if it was it that published it, but it's, really fantastic. Read, talk to me a little bit about those launch weeks and then 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 X founders. If there's a reason why they're X founders, they probably have spent the past three years grinding, trying to product find product market fit, talking to customers. These are all in the traits that you really want from a good product engineer. And then they joined 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 you As you're growing bigger that you're, I don't see either you're in 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 would, 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 working well, then we know that the team are doing something right. And, where we don't want to go is too strict. We basically set up our organizations for principals. We have a very principal 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 and 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 in 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 were to post on this about a year ago But one of the unique insights that I've noticed lately is that shipping speed is It's 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 We 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 a 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 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 It's cool. I would say maybe, there's 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 is 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, we first and foremost just wanted to solve problems with databases and then maybe our unique positioning just It came around because we wanted to be different, to be recognized. We use a lot of memes. That was a happy accident. My, my co founder and is very good at memes.
Viviana Faga: We used to call him the meme lord in the board meetings. And it's he loves it. He really, and he like spends time on it, which is great.
Paul Copplestone: Exactly. Yeah. Yeah. He does a great job. And he's the CTO as well. So that's the funny thing. But 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, to 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's a couple 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, they 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 growth. The thing that's quite different from maybe the SAS is generally the founders of 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 like for example firebase is a no sql 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 languages because they're so unstructured themselves. So you can feed it a database schema, for example and it's very structured and then it can really understand the context of your database and it can suggest to you some charts that can tell you which query to run and 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 and then ai came along and we stripped out all the forms and just turned it into a chat bot 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 what's called Postgres.new, but we've relabeled it to database.build. And you can build databases inside your browser using AI. And 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 significant, 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. new, V0s, the Lovables, it's really, yeah, 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's 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 profile? 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, I was visiting or a friend came to visit me and 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, bulk. new and 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 the, 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 the, 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, there'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 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 You know some scalability stages.
So right now, you know 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 re 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, you and I have a lot of conversations about this, especially early on. How's 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, I 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, you don't, 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 we, 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 up market 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 like your home page is what you are Right. It's people are trying to learn who you are So the first place that goes 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, cool.
It's really going to impact your business. And I 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 Neil's, 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 would 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 challenges 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 x founders because they typically have faced far more challenging things than what we've had as Supabase because what's more challenging than Having your back against the wall your own company is about to die. You 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, Supabase as a comparison.
Viviana Faga: Sure. Especially given the fact that you're, you're probably working remote, right? And so you get to work when you want to work on what you want to work. And like 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, I said, this is, Ant is a 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 like 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 like 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've, 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? Like 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 for what I've noticed and they get to contrast them with a new developer. Indie developer has like a choice of any type of tool that they can enterprise developer inside 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 you know steer the direction of the roadmap.
So and our success team as well So 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 on the security reviews, the legal, these things take a year, but those are the ones that 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, 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 our let's recreate this demo day like Event three years three months in the future and we did that and we shipped something big And then when we're 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 we, in that first one, I think we saw our top of funnel, our 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, can, 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 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, but Slack for synchronous comms, Notion for async and, 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, request 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, 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 self aware, kind of wedded to that particular solution and over time, especially in an async and 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 this too much distance, they're attacking your solution.
So to counteract that, this three 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 actually come up, 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're built with 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, and then we 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 kind of 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 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 FaceTime 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 an, 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 kind 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's stage, 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 if 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 are, what's some of the advice that you would give them?
Paul Copplestone: Yeah, I think, I think the YC culture is pretty, pretty clear on this one. You just listen to your customers, solve a pain point you work diligently on that all the Time. there is some advice. There's a lot of cliche advice out there. Often it's you give up too fast on, 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 a 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 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.
