Y CombinatorWhat Happens When Everyone Can Build Software
CHAPTERS
- 0:00 – 1:29
Supabase’s agent-driven inflection: everyone becomes a builder
Paul Copplestone opens with a vision that AI will turn far more people into “builders,” enabling customization without waiting on engineers. The hosts set up Supabase’s role as a default database choice inside agentic coding tools, framing a shift toward making products that agents want.
- •Paul says AI will make “everyone in the world with access to AI” a builder who can tweak apps and UI without being beholden to others
- •Garry frames a shift from “make something people want” to “make something agents want,” noting a large share of new activity coming from agents
- •Supabase is introduced as an open-source Postgres backend increasingly used by agentic tools
- 1:29 – 2:35
Growth metrics: signups, revenue, and database creation at massive scale
The conversation turns to recent growth and the metrics Supabase tracks. Paul shares rapid acceleration across signups, revenue growth, and databases under management, calling it a major inflection.
- •Paul says Supabase has 13 million signups now, up from roughly 3 million about 12 months prior
- •Paul says revenue will grow 4x this year
- •The hosts highlight over a million databases being created per week
- •Paul says databases under management are approaching 50 million, up from 8 million a year ago
- •Paul attributes growth to both software engineers building aggressively and new non-engineer builders coming online
- 2:35 – 3:24
Three eras of Supabase: dashboard → API → code-first for agents
Paul outlines three phases in Supabase’s evolution: starting as a dashboard-driven experience, then shifting to APIs, and now moving to a code-first workflow optimized for agents. He emphasizes CLIs, Git-native flows, and being a default choice in LLMs.
- •Paul describes Supabase’s three chapters: dashboard company, then API company, now code-first company
- •He says agents prefer code-first workflows, often via CLIs
- •Paul points to the advantage of being selected as a default database option by LLMs
- •The team pushes “Git native” and infrastructure-as-code parity with dashboard features
- •Paul says fewer people visit dashboards now, forcing a product shift toward agent-friendly workflows
- 3:24 – 4:34
Why open source matters: agents, debugging, and enterprise trust
Open source comes up as a key ingredient in Supabase’s adoption, especially in an agentic world. The group discusses how source visibility helps agents troubleshoot, and how enterprises may demand inspectability for security reasons.
- •Paul says it’s hard to know the counterfactual, but open source was critical and everything they do is open source
- •He describes supporting the broader Postgres ecosystem and “sprawl across many communities”
- •Garry suggests agents benefit from open source because they can inspect the code when something goes wrong
- •Paul says security pressures make source inspection increasingly important for enterprise adoption
- •The discussion frames open source as both a usability and trust advantage
- 4:34 – 6:29
“Builders” vs traditional developers: new adoption without losing conversion
Paul explains a widening customer base where builders who are not software engineers are arriving in large numbers. He notes an unusual pattern: top-of-funnel signups accelerate while activation and conversion also rise, driven by improving models.
- •Paul says the world is seeing “builders” coming online in large numbers, many without engineering backgrounds
- •He highlights that activation and conversion are rising alongside accelerating signups
- •Garry clarifies the builder category as people who need to build something, not necessarily engineers
- •Paul describes pent-up ideas from domain experts who no longer need to convince engineers to help
- •Paul says he doesn’t see a clear ceiling yet for product-led growth in this new environment
- 6:29 – 9:59
Personalized apps emerge: domain experts and “would’ve never been built” projects
The hosts and Paul trade examples of what new builders are creating. A standout story involves a taxi driver who built a local taxi app from his phone, illustrating how AI tools can unlock entrepreneurship for people outside tech.
- •Harj shares an example of a domain expert building sophisticated personal finance tools and bank integrations that previously would have required an engineering team
- •Paul says domain experts can now build directly into niches they understand deeply
- •Paul recounts meeting a taxi driver from Brazil who built a mini ride-hailing app from his phone
- •Paul highlights the excitement and entrepreneurial energy this unlocks, including for blue-collar workers
- •The group emphasizes that knowing what to build becomes the key differentiator as building gets easier
- 9:59 – 12:10
From markdown to databases: Harj’s “control tower” and why UI still matters
Harj describes building a personal “control tower” app spanning email triage, finances, and health, after realizing markdown alone doesn’t scale. The discussion centers on how personalization becomes a superpower when you’re building for one person—yourself.
- •Harj says he originally wanted everything in markdown and predicted “no UIs,” but learned you hit a point where databases and UI become useful
- •He describes a single app with sections for email triage, finances, spending, and health tracking
- •Harj claims his personal finance section feels at least feature-parity with existing consumer products, and sometimes better due to personalization
- •He describes using personal context to categorize transactions and make sense of health changes with travel context
- •Paul says finance and health are common areas where people want their own data and a unified database
- 12:10 – 14:15
Personal databases & data ownership: escaping “boxed-in” agents and centralizing life data
The conversation broadens to the idea that individuals will maintain their own databases to power multiple apps and agents. Paul and Harj describe a shift from being tied to a single agent or vendor toward owning a durable “store of record.”
- •Paul says using personal agents can feel like routines and CRM are getting boxed into one agent, motivating him to extract data into a separate store
- •Harj argues the database becomes the valuable store of record, enabling many apps/agents on top
- •Jared notes the historical shift from few large corporate databases to potentially everyone having their own database
- •Harj describes a personal file-ingestion workflow where an agent classifies uploads and stores them in Supabase
- •Garry mentions using Supabase’s S3-compatible files and that it’s a default component inside one of his tools
- 14:15 – 16:59
Scaling to billions of databases: cost, compute scarcity, and a SQLite-compatible tier
Paul responds to the idea that everyone could spin up databases, sketching a future scale that requires new architecture. He discusses compute constraints, the need for lighter-weight options, and an approach that supports both small prototypes and massive growth.
- •Paul imagines a world where massive numbers of users could each launch databases frequently, pushing unprecedented database-scale requirements
- •He jokes better AWS negotiations might help, while noting everyone wants computers right now
- •Paul describes acquiring Turso and positioning it as compatible with Postgres and SQLite
- •He introduces “Supabase Spark” as a tier aimed at getting-started workloads with the same initial experience
- •Paul reiterates a “prototype to petabytes” vision, ensuring users can start small and scale up dramatically
- 16:59 – 17:58
Serving both ends of the market: scale-down prototypes and scale-up enterprise workloads
Harj challenges the traditional database-company path of racing toward enterprise features, noting Supabase’s interest in smaller workloads too. Paul explains they’re building for both extremes simultaneously, which is difficult amid rapid growth.
- •Harj contrasts the classic path of moving from startups to enterprise with Supabase’s push toward SQLite-like workloads
- •Paul says they must do both ends: scale up and scale down
- •He describes two product lines: one for scaling up to very large data and one for prototype/SQLite-style use cases
- •Paul emphasizes the challenge of executing both while hiring and growing quickly, even with AI support
- •The conversation frames this as necessary to support the expanding builder market
- 17:58 – 19:58
AI adoption inside Supabase engineering: tool freedom, testing intensity, and confidence shift
Garry asks about rapidly rising internal use of coding agents among Supabase engineers. Paul attributes it to giving teams freedom rather than strict policy, improving model quality, and a greater emphasis on testing to ensure reliability.
- •Paul says Supabase has no internal AI policy and gives engineers access to tools they want
- •He describes a sharp increase in adoption as engineers become convinced models can do better work
- •Paul says internal projects built with agents are substantial, not just trivial code
- •He highlights increased focus on testing and adopting testing tools to validate AI-generated work
- •Garry notes a broader ecosystem trend of exploding test counts and CI emphasis
- 19:58 – 27:09
How each product era was triggered: developer pain, API demand, and the “no dashboards” reality
Paul reflects on the specific insights that drove Supabase’s transitions between eras. He describes building an Airtable-like UI over Postgres for developer usability, then adding APIs to support programmatic database creation, and finally shifting to code-first to match agent workflows.
- •Paul says early on they built a dashboard because even software engineers struggled with databases
- •He describes the initial vision of an Airtable-like UI backed by Postgres
- •Paul says the API shift was prompted by a user needing to launch many databases programmatically, which later aligned with new builders on the platform
- •He states that now “no one visits dashboards anymore,” pushing Supabase to code-first, Git-native parity
- •He notes significant re-architecture of CLI and workflows for sandboxed code environments
- 27:09 – 31:31
Building for personal agents: dogfooding via voice, imagining agent conferences, and agent-friendly UX
Paul explains a growing obsession with building for personal agents and shares how he dogfoods by interacting through conversation rather than inspecting code. The group brainstorms the idea of conferences designed for agents and discusses practical product changes that make agents succeed, like actionable error messages.
- •Paul says he’s become bullish on personal agents after experiencing what they can do when his EA was away
- •He describes dogfooding by talking to an agent continuously and avoiding looking at code to simulate a non-engineer workflow
- •Jared imagines sending an agent to learn product updates and integrate new features automatically; the group riffs on an agent-focused conference concept
- •Paul says improving error messages is key so agents can self-remedy instead of requiring humans to Google fixes
- •He frames winning agents in two stages: being selected by the model and preventing churn when agents get stuck
- 31:31 – 38:42
Agent-first design and evals: model comparisons, internal suites, and self-improving loops
The discussion dives into how Supabase tests its product for agent usage. Paul describes using evaluation suites across models and prioritizing use-case testing; Garry shares how he builds eval datasets from production traces and runs continuous improvement loops.
- •Paul says Supabase tests across different models, tracks which build best, and maintains internal eval suites
- •He mentions evaluating models specifically on Postgres-related capabilities and building skills around adoption
- •Paul says much engineering effort now goes into testing specific use cases and building suites around how people build
- •Garry describes extracting production traces into an eval dataset with many categories like efficiency and latency, then looping improvements automatically
- •Garry outlines a workflow where failed attempts are documented in markdown and stored for future reference
- 38:42 – 48:45
The future of coding and entrepreneurship: talking to agents, durable categories, and staying adaptable
In the closing stretch, they discuss whether builders will need to understand evals or whether coding will become conversational. Paul shares a personal example of building a developer site through dialogue, then reflects on entrepreneurship outcomes, fundraising expectations, and how Supabase stays adaptable in a fast-changing world.
- •Paul describes building a developer site by chatting with an agent and seeing changes implemented quickly, calling it a glimpse of the future
- •They debate whether future builders will need to know about eval frameworks or whether tools will abstract it away
- •Garry and Paul discuss how smaller teams can reach meaningful revenue and profitability, changing the role of fundraising as a “badge”
- •Paul says choosing durable categories matters, noting databases’ long lifespan and his confidence they’ll remain essential
- •Paul emphasizes dogfooding, partnering with ecosystem players for feedback, leaving capacity for experimentation, and adapting quickly as conditions shift
