Paul Copplestone, CEO of Supabase - don't kill your channel
Supabase CEO Paul Copplestone on why he stole 'don't kill the channel' from Groupon's collapse, why the best cultural onboarding happens before someone joins, and why he still leans into raw SQL even as vibe coders flood in through Bolt and Lovable.
Paul Copplestone is the cofounder and CEO of Supabase, the Postgres development platform now used by over 3 million developers. We talk about the discipline it takes to cross into enterprise without losing the developer community that got you there in the first place — what he calls not killing the channel.
We get into how Supabase keeps its culture intact while roughly doubling headcount, the configuration-over-customization technique they use to serve everyone from solo indie hackers to enterprise buyers on one product, and how the vibe-coding wave through tools like Bolt and Lovable has actually reshaped Supabase's own product design.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
How do you think about hiring internally versus working with contractors as you scale?
The mandate is essentially: hire the minimum number of people internally, and work with external people otherwise. You trade cash for culture — external contractors are more expensive, but it keeps the internal team smaller and keeps you from getting drift from people who are far removed from developers and open source. Even with people we do hire internally, as the team grows it starts to feel like a game of telephone — you spend a lot of time setting the culture, or maybe not even setting it, you just work, and then you get less facetime with each new hire than the last one had.
How do you actually make sure new hires pick up the culture as the team doubles?
The best cultural onboarding happens before people join, not after — ideally people join Supabase because they already know how we operate, rather than joining for their skill set and then being told, by the way, can you act like this. Hopefully they've seen our Twitter, seen our memes. Stripe does this well with a public culture page of about twenty bullet points; Netflix's famous onboarding doc is another example — you know going in that they operate like high performers, like a sports team, and you gravitate toward that if it's what you like. Early on we were very async, close to one meeting a week per team, and if you were an extrovert you just wouldn't fit — we had people leave literally because it was too async for them. As we get bigger it gets harder to maintain: at some point it becomes train-the-trainer, where we trust that we trained the early people well enough that when they hire people, they do a great job training and culturally onboarding them too. If you mess that up early, you can't really go back and fix it.
There's a common cycle where a dev tool takes a big enterprise deal, gets pulled off course, and loses its developer base. How do you avoid that?
It happens over and over — you start as an open-source tool, build a good community, usually founder-led, start making money, maybe raise from VCs, and once you're bigger and have your community of champions, enterprise comes in with deep wallets and says something like, I'll give you a million dollars, but I need it to work this specific esoteric way, sign these terms, deliver by this date. Who says no to a million-dollar contract, especially early on? The problem is the next enterprise customer comes with their own bespoke requirements, then the next, and instead of one product for your whole community you end up with ten or twenty bifurcated products. The cadence slows, the founder's focus shifts to enterprise, you make a lot of money but your growth tails off, and by the time you look back and say let's get back to our community, the point of no return has usually already passed — you can't go top-down back to developers, you have to keep your focus on developers the whole way through. Stripe is a really good example of doing this well. So you basically have to say no to a lot of early bespoke enterprise asks, which is where we are now: laying the foundations to build for enterprise while still serving the developer pool.
How do you actually serve an indie hacker and an enterprise buyer on the same product without pulling it in two directions?
One technique is configuration over customization. When an enterprise asks for something bespoke, like a very specific login method, instead of building that one thing, you go one abstraction level up: how do we add a hundred login methods, which usually just means adding the underlying protocol. You add knobs that can be turned on and off so the product becomes almost infinitely adjustable, and you expose more configuration as a customer moves through the gates from indie developer toward enterprise. On the database side, most indie developers want something cheap and don't care as much about speed; as they get traffic they start caring about read replicas and faster disks, and you expose those gradually. The tagline is build in a weekend, scale to millions — you want someone to be able to insert into that journey at any point, from a completely free tier all the way to enterprise, and have the platform still feel seamless the whole way through, with sensible defaults at every tier.
Tools like Bolt and Lovable are built on Supabase, and a lot of your new users are vibe coders now. How has that changed your product design?
That developer spectrum used to run from front-end developer to hardcore database engineer, and we sat about 25% along it — we wouldn't make it just a front-end tool, we'd actually teach people what a database is. This year that spectrum has basically swung into vibe coder or builder as a completely different ICP who thinks and uses the product differently. I see gradual exposure almost as a duty rather than a choice — you can't yet prompt your way to a mature enterprise application, so it's about how we expose more of the real workflow over time, not whether we should. One of the first things we built was a table editor that looks a bit like Airtable, and right below it is a SQL editor — for a while we considered collapsing the two, but I like keeping them separate: people think in tables first, the SQL editor might look scary, but they can see it's there, and eventually they get exposed to it, often because the community points them there through Reddit or Stack Overflow or ChatGPT. We also leaned into SQL rather than abstracting it away entirely, because I think it's genuinely a good industry skill for people to pick up. Ironically, AI ended up letting us strip out a lot of niche UI panels, because the discovery mechanism is now just the chat assistant, which actually simplified the dashboard.
You've written about 'friction logs.' What are they, and why do you rely on them so much?
It's one of the best ways to get real feedback, because if you just ask someone to test a feature and give feedback, it's hard for them to know what to say — they'll usually just say it's great. A friction log means you try a feature and log every step you take as you go, especially the parts where you felt stuck, and hand that log to the team so they can step through your actual thinking. We do this a lot: whenever someone in the community tests a feature, we ask for a friction log, and everyone who joins Supabase does a dogfooding project and writes one as part of onboarding.
Where does 'don't kill the channel' come from, and what does it mean for how you market to developers?
I picked it up from Duolingo, who apparently took it from Groupon — at this point it's basically a meme, and one of my cofounders had actually worked at Groupon China. The Groupon story: they emailed one deal a day, and it worked great, so the team pushed for two emails a day, which also worked, so they pushed for three, and kept going until they hit six a day — at which point people got fed up and unsubscribed, killing their entire channel, since once someone unsubscribes you're not getting them back. That became Groupon's rule number one from the CEO: don't kill the channel. For us, the tension is between marketing and developers who hate being marketed to, and our channel is our community — anything that builds friction with that community, whether it's aggressive marketing or dark patterns in the product, eventually kills Supabase. Our own account is mostly memes and developer culture, not constant promotion, and as we grow, one founder has to keep being the voice of the developer community internally — the person who says a feature matters even if it earns no revenue and only one person asked for it, because someone with a strong voice has to hold that line, the way the Groupon founder probably should have when his team kept pushing for more emails.
You've said you'd never relicense away from open source. Why hold that so firmly?
It's not really a question of whether it's good business practice or something we're worried about — it's just our philosophy: dev tools should be open source, that's how we think the world should work, and more things should be open source ideally. I get asked about it constantly, from investors to community members, and my answer is the same: I'd only want to work at an open-source company with open-source developers. Yes, we lose business to people who choose to self-host instead of using our hosted platform, but I'm genuinely happy for them — I want their developer experience to be great either way. People worry AWS could clone us the way they did with Elasticsearch, but I'm not that concerned, because our whole advantage is the integrated, seamless experience, not just the underlying tech — you can't fork taste. If the hosted experience is good enough, self-hosting just isn't worth people's time, even though it's always there as an option.
How do you actually land inside a big enterprise — from one small team quietly using Supabase to company-wide adoption?
The good thing about having three million developers on the platform is you already have champions inside almost every company — they're a bit like an internal extension of our community, and they generally want to bring the product in and help show that Supabase is great. That can be as simple as running an internal hackathon or a brown-bag lunch session. Once it's genuinely enterprise-scale, you need more of a pincer motion, bottom-up and top-down together, because the decision maker, the economic buyer, and the actual users are all different people with different concerns — with an SMB they're often all on the same call, but with a big enterprise you need each of those people to already know about Supabase before they ever get to a formal decision.
What are you most excited about right now?
We've got three big scalability initiatives going at once. Multigres, which lets you run a limitless number of nodes — it's built by the creator of Vitess, the tool YouTube built to scale MySQL with sharding and high-availability tooling, who wanted to do the same thing for Postgres and came to us a couple of weeks before we announced it. There's OrioleDB, which replaces Postgres's storage engine and is about five times faster than the default. And there's an Iceberg initiative with the S3 team at AWS that lets us seamlessly offload data between the database and S3 in Iceberg's columnar format, so you can effectively store an infinite amount of data. In a lot of ways we're being opinionated about being unopinionated — letting people choose their own path for how they want to operate their data, and trying to make that whole journey feel seamless, the same way we have for the first five years. All three will be open source, so people can self-host them too if they want.
Links & references
- Paul's LinkedIn ↗
- Paul's X ↗
- Paul's blog ↗
- Supabase ↗
- Enterprise Sales vs Product-led Growth (how DevTools die) ↗
- Friction logs ↗
- Ant Wilson's LinkedIn ↗
- Multigres: Vitess for Postgres ↗
This episode is brought to you by WorkOS.