What Happens When Everyone Can Build Software

The host introduces Paul Copplestone, Supabase’s co-founder and CEO, describing Supabase as an open-source Postgres backend used by tools such as Cloud Code and Codex. Supabase now has 13 million sign-ups, creates more than a million databases per week, and gets roughly 70% of its new activity from agents. Paul says that twelve months earlier the company had about 3 million users rather than 13 million, managed roughly 8 million databases rather than nearly 50 million, and expects revenue to grow fourfold this year. Paul attributes the inflection to two changes: software engineers are building with agents, and many more non-engineers are becoming capable of building software. He distinguishes “builders” from traditional software engineers: they may simply have a problem to solve, open a coding tool, and create an application without ever identifying as developers. The host and Paul argue that this lets domain experts pursue ideas they previously could not get an engineer to work on. As an example, the host describes a fintech founder who could previously write only small Ruby scripts but can now build sophisticated personal-finance tools using his knowledge of banking and financial operations.

Paul describes three eras in Supabase’s product strategy. The company began as a dashboard product, modeled partly on Airtable: the founders wanted a friendly interface on top of Postgres because even developers struggled to use databases. It then became an API company after a customer said they needed to create many databases programmatically. That 2021 shift positioned Supabase well when products such as Bolt and Lovable began building on top of it. The current phase is code-first and agent-oriented. Paul says agents generally prefer code and command-line interfaces rather than dashboards, so Supabase has reworked its CLI and infrastructure-as-code workflows to operate in sandboxes. The company also benefited from becoming a default database choice in language models. Open source was important, though Paul says the counterfactual is impossible to know: Supabase supports the broader Postgres ecosystem rather than only its own tools, which gives it reach across multiple communities. The speakers suggest agents particularly value open-source systems because they can inspect source code when something fails, while enterprises may increasingly want source access for security review.

Paul explains that he has been building a personal “control tower” using OpenClaw. He initially resisted both user interfaces and databases, preferring chat and Markdown files, but eventually found that a database and UI were necessary. The application combines email triage, workouts, finances, files, and other parts of his life. He says its finance section has feature parity with products such as Mint or Monarch, while being more useful to him because it can apply personalized context—for example, identifying a transaction by connecting its name to people in his personal knowledge base. The speakers argue that the database becomes more valuable as it unifies information from different systems. Health data can be combined with calendar data so an agent understands that a weight change happened during travel; files forwarded by email can be classified and connected to relevant parts of someone’s life. The host says he became uneasy about putting his routines and CRM inside one agent, so he is separating the underlying data from the agents that operate on it. Paul agrees that users should own the database and attach different applications or agents to it, rather than locking their information inside one vendor’s database. He says he would not have understood the appeal of a personal database a year earlier, but AI now makes it useful.

The host asks whether everyone with AI access will eventually have a personal Supabase database containing health, finances, relationships, and other information. Paul says he believes everyone with access to AI will become a builder of some kind, able to customize applications instead of being dependent on someone else. He frames Supabase as an “index company”: the mission began with getting onto the stack on day one for YC startups, but the aperture has widened as the population of builders expands. Paul points out the scale implied by this future. Supabase currently launches about one million databases per week, while ChatGPT reportedly has 1.2 billion weekly active users; if each wanted to launch something monthly, that would mean roughly 1.2 billion databases per month. He says Supabase cannot necessarily use heavyweight Postgres infrastructure for every workload. After acquiring Terso, the company plans a Postgres- and SQLite-compatible tier called Supabase Spark for lightweight prototypes, while retaining systems that can scale to petabytes. The company’s goal is summarized as “prototype to petabytes.” Paul says Supabase is trying to serve both ends of the market, even though building for early personal workloads and enterprise-scale applications simultaneously is difficult.

Paul says Supabase has not imposed an internal AI policy; engineers can use whichever tools they want. In a poll, the share of engineers writing 80% of their code with coding agents rose from 10% to 60% in six months. The resulting work is not merely throwaway prototypes, and the company is investing heavily in testing because agents can generate much more code and need reliable ways to verify the result. The speakers focus on error messages as a simple but important way to win agents. A conventional error message tells a human that something went wrong, but Supabase is rewriting messages so an agent is told how to fix the problem or which documentation to read. Paul says there are two stages to winning an agent: first, being selected by the model; second, preventing the model from abandoning the product when it gets stuck. Supabase runs evaluations across different models, maintains an internal evaluation suite, and tests realistic Postgres use cases. Much of its engineering effort now goes into testing how people and agents build rather than only implementing features. Paul imagines a future conference attended by agents, where they could learn about new Supabase capabilities and integrate them into code without a human needing to understand every feature.

The conversation returns to Supabase’s history and the market conditions that made the company possible. Paul credits products such as Parse, Firebase, MongoDB, Heroku, and Postgres itself with showing that developers could use specialized platforms instead of going directly to a hyperscaler’s raw database service. Parse and Firebase demonstrated the appeal of backend abstractions, while MongoDB and Atlas helped establish that database companies could be legitimate businesses rather than merely wrappers around RDS. The host compares Supabase’s strategy with AWS and Stripe: acquire customers at the beginning of their journey, give them a good experience, and grow as their businesses grow. Paul says migrating databases is extremely difficult, so the company wants to be present on day one and make customers reluctant to leave. That “day one” is changing, however. It used to mean an early-stage startup; now it may mean an individual or an agent building a personal tool. Paul says Supabase is deliberately serving both prosumer and startup customers. Personal applications may not scale like venture-backed companies, but their users can keep accumulating data for the rest of their lives. He describes that expanding personal information as another growth vector for the company.

The host and Paul discuss the growing gap between AI capabilities and the number of people who know what to build. The host describes coding agents as approaching recursive self-improvement loops, while society still has relatively few people who can define valuable problems and direct those systems. Paul is optimistic rather than fearful: he has previously built companies serving blue-collar workers, and he sees Supabase enabling more people to become entrepreneurs and build useful tools for their own communities. They connect this shift to startup fundraising. Vertical SaaS companies with $5,000 to $10,000 in annual recurring revenue once had an easier path to a Series A, but investors are now more interested in horizontal and AI companies. At the same time, a software company may reach $10 million, $15 million, $25 million, or even $50 million in revenue with a team of only 10 to 15 people. The host says a company with 15 employees and $2 million in ARR could be making about $1 million annually at 50% margins, which may be a better outcome than raising more capital. Paul says founders have traditionally treated fundraising as a badge of achievement; in the new environment, avoiding unnecessary fundraising may itself be the achievement.

Paul says databases give him confidence because they have existed for roughly 50 years and will likely continue to exist for another 50. His advice is to choose durable categories when making a life-sized bet, while accepting that the way customers use those categories can change rapidly. Supabase does not try to predict every development; instead, it aims to adapt faster than competitors and preserve enough capacity to respond when new opportunities appear. He warns that developer tools often begin with a strong developer focus, then move upmarket, become corporate, and lose the qualities that users loved. He cites Stripe as an example of a company that continues to focus on new ways of building. For Supabase, dogfooding is central: Paul uses the tools himself, looks for places where he gets stuck, and treats those failures as unusually valuable feedback. The company also partners with important ecosystem players, even though many apparently promising collaborations fail. The episode ends with Paul saying that the successful experiments are the ones that let Supabase ride a new wave with its partners. His near-term priorities are maintaining adaptability, leaving capacity for unexpected shifts, and continuing to build for the next form of user—including agents that may soon interact with infrastructure more often than humans do.