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

First Round Capital

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.

CHAPTERS

Jump to publisher timestamps

Chapter summaries

From side project to massive scale: what Supabase is and why it matters
The host sets the stage for Supabase’s growth from a side project into a widely used backend platform. Paul frames the company’s ambition and hints at key themes: developer pain, avoiding lock-in, and building for long-term scale.
- •The host introduces Paul Copplestone and positions Supabase as an open source backend used by millions of developers
- •Paul describes noticing how hard it is for developers to use databases and seeing that as opportunity
- •Paul states the ambition to build a “generational database company”
- •The host previews themes including refusing to lock customers in and building toward agent-run database operations
Earlier startups: why they weren’t built to become enormous
Paul reflects on his first startup experiences and why they didn’t reach the same scale as Supabase. He emphasizes how many things must go right, including market dynamics and product-market fit, and shares what he learned from ambitious partners.
- •Paul argues startup success requires many things to go right, including luck
- •He explains his first startup was geographically constrained and lacked pure product-market fit
- •He contrasts market dynamics between the US and Southeast Asia and how that affects execution
- •He credits a co-founder for lessons in ambition, sales, fundraising, and keeping a high hiring bar
Nimbus and the origin story: building real-time on Postgres
Paul explains how his second company’s tech stack became the foundation for Supabase. Hitting scaling limits with Firebase for chat pushed him to build real-time features on Postgres, open source the work, and follow the traction.
- •Paul built a chat-centric product and used Postgres plus Firebase for real-time
- •Scaling issues prompted him to recreate real-time functionality on top of Postgres
- •He built it using Elixir and Phoenix and open sourced the component
- •Early traction on Hacker News signaled developer interest and clarified the direction toward a Postgres-based database startup
High conviction, tailwinds, and choosing the “operate” space
Paul describes why the Supabase opportunity felt obvious: developers struggled with databases, and Postgres momentum created tailwinds. He explains the durability of operating databases at scale and how Supabase leaned into community and product-led growth rather than splitting focus too early.
- •Paul felt strong conviction because database usability was a clear developer pain
- •He notes Supabase benefited from Postgres becoming more successful than he could have predicted
- •He frames Supabase’s moat as operating databases over years at scale, not just launching software
- •He explains focusing on community and PLG while building in “onion layers” rather than scattering efforts
Unlearning “tall poppy,” fundraising lessons, and going all-in on async remote
Paul contrasts his early founder mindset with how he approached Supabase. He shares learning fundraising dynamics, avoiding premature blitzscaling, maintaining a high bar for talent, and committing fully to an async distributed model to prevent HQ-centered decision gravity.
- •Paul describes New Zealand’s “tall poppy” mindset and how he unlearned it
- •He separates fundraising as a distinct skillset from building the business
- •He emphasizes finding product-market fit before blitzscaling and reflects on holding back hiring too long at Supabase
- •He explains why Supabase went fully distributed and completely async, seeing it as a superpower
Accidental Hacker News breakout and the power of positioning
Paul identifies early moments of pull, including an unexpected Hacker News post that surged after a tagline change. He explains how positioning can unlock product-market fit and how early community feedback shaped the next key feature launches.
- •A Hacker News post right after changing the tagline drove a major early spike
- •Paul’s takeaway: product-market fit can hinge on product positioning fit
- •Community demand surfaced missing pieces like auth, even though he initially wanted to focus on databases
- •Launching auth before Demo Day changed growth slope and reinforced the value of shipping toward clear demand
Roadmap building: balancing demand with technical taste (and resisting functions)
Paul explains how the early roadmap was shaped by both community requests and the team’s technical instincts. He describes Supabase’s preference for “primitives,” and how sustained demand eventually pushed them to launch functions despite initial resistance.
- •Roadmap decisions were a hybrid of community demand and internal technical taste
- •The team aimed to ship flexible primitives rather than opinionated products
- •Edge functions were the standout example of strong, repeated community demand
- •Paul describes how launch weeks created repeated growth bumps and validated what resonated
What great DX means and how shipping changed as Supabase scaled
Paul defines developer experience as minimizing friction and accelerating the “time to value.” He contrasts early improvisational shipping—where engineers could rewrite libraries hours before launch—with today’s need for security, billing, anti-abuse guardrails, and staged rollouts.
- •Paul’s key DX metric is time to value and fast access to the developer’s “aha moment”
- •Bad DX is described as constant paper cuts and blockers that cause developers to give up
- •Early building involved rapid iteration and bold launches with minimal fear of shipping
- •At scale, new products need a rollout pipeline (including a “labs” stage) and operational readiness
Solving the “graduation problem” by winning day-zero and “smuggling Postgres in”
Paul lays out a deliberate strategy to be the default choice at the start of a project and still scale with customers later. He explains how the “open source Firebase alternative” positioning helped win early workloads, while Postgres provided a path to production-scale credibility.
- •Paul says the graduation problem was part of the strategy from the start
- •He argues that winning “day zero” matters because developers choose tools before they know what they’ll build
- •Supabase leaned on the Firebase-alternative positioning to become a default starting point
- •He describes initially downplaying Postgres, then gradually leaning into Postgres-centered messaging and memes as the ecosystem shifted
Open source as philosophy, not a funnel tactic
Paul explains how open source shaped Supabase’s product packaging and trust. He emphasizes there’s no tracking, broad feature availability, and a desire to contribute back—aligned with the team’s values rather than a gated onboarding strategy.
- •Paul says everything they develop is open source except certain platform and billing components
- •He highlights a self-hostable stack experience without tracking and with free usage
- •He rejects an approach of gating features as a conversion strategy, framing it as philosophical alignment
- •Open source enables hiring and supporting maintainers and contributing back to the ecosystem
Three AI tailwinds: pgvector, “vibe coding” platforms, and CLI/MCP agent workflows
Paul breaks AI-driven growth into three phases that each expanded Supabase’s demand. He covers early vector/embedding adoption, a surge from AI app builders launching many databases, and a newer wave driven by coding agents using CLI and MCP-style workloads.
- •Phase one: early vector momentum and offering pgvector created meaningful uptake
- •Phase two: two customers created massive database creation volume that initially looked like a DDoS
- •Paul explains why Supabase supported AI builder platforms despite internal skepticism about prototypes
- •Phase three: fast-growing agentic tools increased CLI/MCP workloads across a large developer base
Hypergrowth “success problems” and planning the platform for agents
Paul describes the operational chaos of scaling—like capacity constraints that can block new database creation. He then explains how he thinks about a multi-year horizon: shifting from dashboard-first to CLI-first, code-first parity across surfaces, and enabling self-driving databases.
- •Paul describes scaling as constant “success problems” that distract from shipping launches
- •He mentions resource constraints that can threaten the ability to launch new databases
- •He predicts a shift toward CLI-first, code-first, and Git-first workflows
- •He outlines a vision for parity across dashboard/CLI/MCP and for agents to help operate databases over time
Egoless, hypercompetitive async culture—and why it scales with AI searchability
Paul explains Supabase’s culture as distributed, async, and deeply documented, which makes information searchable and reduces coordination costs. He highlights an “egoless” ethos rooted in open source pride and competitiveness, and how they assess fit for that mindset in interviews.
- •Async work is reinforced through writing, recordings, and captured knowledge across tools
- •Paul describes using AI to query company knowledge, reducing dependency on specific individuals
- •He calls the culture egoless but also “hypercompetitive,” rooted in open source craftsmanship
- •He explains signs of fit in interviews, and says he prefers working with people who aren’t difficult to collaborate with
Fundraising playbook: lead gen, switching mental modes, ambition and sequencing
Paul outlines how he approaches raising capital as a distinct discipline from building. He emphasizes building investor relationships early, communicating ambition clearly, and showing credible sequencing toward long-term goals—even if fundraising itself feels like a distraction.
- •Paul recommends meeting many investors early to build lead flow
- •He describes switching from builder mindset to fundraiser mindset
- •He argues investors need to believe both the ambition and the plan to get there over decades
- •Paul says he doesn’t enjoy fundraising, but sees it as necessary for a database company
Go-to-market evolution: layering into enterprise and product-led sales with incremental comp
Paul explains how Supabase expanded from PLG into enterprise while staying focused on broadly beneficial roadmap items. He details a product-led sales motion driven by usage triggers, help-first outreach, and compensation based on incremental uplift rather than total account revenue.
- •Paul describes moving from indie/SMB toward larger workloads by adding layers rather than jumping segments
- •He says they decline bespoke enterprise requests that don’t benefit many customers
- •The sales motion is triggered by product signals and framed as support to solve real usage problems
- •Sales compensation is tied to incremental uplift compared to a control group, avoiding credit for growth that would happen anyway
Operating philosophy: avoiding lock-in, scaling pain, and kaizen-style continuous improvement
Paul shares non-consensus principles that shape both product and company operations: avoiding customer lock-in and building on open standards. He discusses scaling pains like hero culture and burnout, then explains his process-oriented management style centered on small, unblockable improvements and end-to-end system thinking.
- •Supabase emphasizes no lock-in, open standards, and portability (like being able to export data)
- •Paul describes how success can still be painful through burnout, hero culture, and capacity scrambles
- •He explains his preference for incremental improvement (kaizen) rather than big-bang changes
- •He describes shifting from isolated process optimization to end-to-end systems across product, engineering, and design

Publisher timestamps

Get more out of YouTube videos.

Read along on your phone, search it beside the video, or ask your favorite AI app what was said.