What Happens When Everyone Can Build Software

Supabase's explosive growth (13M users, 1M+ databases created weekly, 70% of new activity from AI agents) reflects a broader shift where coding agents are be

What Happens When Everyone Can Build Software

Abstract

This synthesis examines evidence that autonomous coding agents, rather than human developers, are becoming the dominant consumers of developer infrastructure, and that this shift is accompanied by a broadening of the software-building population beyond professional engineers. Using operational telemetry from Supabase, an open-source Postgres platform, the analysis documents a year in which sign-ups rose from approximately 3 million to 13 million, databases under management grew from 8 million toward 50 million, and 70% of new platform activity originated from AI agents rather than humans. The discussion identifies the product and architectural adaptations this demand implies: code-first interfaces, open-source inspectability as a debugging affordance, remediation-bearing error messages, model-specific evaluation suites, and dual scale strategies spanning prototype and petabyte workloads. Implications for infrastructure design, personal data architecture, and startup economics are considered.

1. Introduction

Developer-tools design has conventionally assumed an end user who is a human engineer operating a graphical console. Evidence presented here suggests this assumption is now inaccurate for a majority of new workload creation on at least one major infrastructure platform. The central thesis is twofold: coding agents - large language model (LLM) systems that author and execute code autonomously - are becoming the primary consumers of developer infrastructure, and access to such agents is converting domain experts without engineering backgrounds into software builders.

Two terms require definition. A builder, as used here, denotes a person who ships functioning software without formal engineering training, typically by directing an agent. Agent-native infrastructure denotes infrastructure whose interfaces, error semantics, and documentation are optimized for machine rather than human consumption. The distinction matters because the design decisions that serve a human reading a dashboard diverge sharply from those that serve an agent parsing an error trace.

This analysis covers four areas: the empirical growth pattern observed at Supabase and its departure from typical funnel dynamics; the mechanisms by which agents select and retain infrastructure tools; the emergence of non-engineer builders as a distinct market segment; and the architectural response required to serve demand at a scale with no historical precedent in databases.

2. Background and Related Work

Three prior frameworks inform the analysis. First, the index company strategy, modeled on AWS and Stripe: capture customers at inception and retain them through growth, such that platform revenue indexes to the aggregate success of its early cohort. Approximately 40% of AWS revenue is reported - as a cited figure, unverified by the source - to derive from startups that began on AWS and subsequently scaled, motivating a "win them on day one, keep them forever" posture.

Second, product-led growth (PLG) theory. Investor consensus had held that PLG motions "tap out" before reaching enterprise accounts; the data below indicate this prediction did not hold over the observed period. Third, the Lindy effect is invoked as a durability heuristic for category selection: technologies with long histories have longer expected residual lifespans, which the source applies directly to databases as a 50-year-old category expected to persist for another 50. Supabase's own product evolution - progressing through a dashboard company, an API company, and now a code-first company - supplies a fourth frame for understanding how infrastructure must adapt to its consumer base.

3. Core Analysis

3.1 Growth Characteristics Under Agent-Driven Demand

Supabase's metrics exhibit a pattern atypical of conventional funnel dynamics: sign-ups grew from approximately 3 million to 13 million year-over-year, revenue grew 4x, database creation exceeded 1 million per week, and databases under management grew from 8 million toward 50 million. Of new platform activity, 70% is attributed to AI agents rather than humans. The notable anomaly is that sign-ups, activation, and conversion rose together rather than the funnel decaying as top-of-funnel accelerated - a pattern the source describes as unusual, since accelerating acquisition typically dilutes downstream quality. This is explained by two compounding forces: software engineers building more aggressively with agent assistance, and a new population of non-engineer builders entering the funnel with genuine intent to ship.

3.2 Why Agents Select and Retain Infrastructure

Agents exhibit systematically different tool-selection behavior than humans. The source argues "no one visits dashboards anymore" among agent consumers, who instead prefer CLIs and code-first modalities that can be scripted and composed. Open-source availability is identified as critical for a specific reason: when an agent's workflow breaks, it can inspect source code to diagnose the failure rather than hitting an unfixable wall at a closed API boundary. This open-source affordance extends beyond Supabase's own codebase into the broader Postgres ecosystem, compounding into community sprawl that benefits the platform indirectly. Separately, enterprises are reported to increasingly require source-code inspection for security vetting before vendor adoption, reinforcing open source as a dual-purpose asset for both agent and enterprise audiences. Supabase's position as a default database inside AI coding tools (Cloud Code, Lovable/Coda) is attributed partly to timing.

Two sequential stages are identified for "winning" agents as users: first, being selected by the model as default tooling; second, preventing abandonment once an agent becomes stuck. The second stage motivated a rewrite of error messages so that agents receive actionable remediation instructions or documentation links rather than generic failure codes, enabling self-correction without human intervention.

3.3 The Non-Engineer Builder Segment

The source documents concrete instances of domain experts building production software without engineering backgrounds: a taxi driver in Brazil built a mini-Uber-style app from his phone, and a fintech founder who had exited a company for over $1 billion now builds personalized finance software with bank integrations as a side project. These examples illustrate a shift in constraint - the bottleneck for solving a niche problem is no longer convincing an engineer to collaborate, but simply knowing what to build. This is reflected in YC's cohort evaluation criteria, which has moved away from requiring a technical co-founder toward valuing applicants who demonstrate clear product judgment.

3.4 Personal Data Architecture and the "Control Tower" Concept

A recurring architectural pattern is the personal control tower: a single application, backed by a personal database, that aggregates email triage, finance tracking, health and workout data, and file uploads. The rationale is that personalized context - such as a system recognizing financial transactions through an individual's own knowledge graph - can outperform dedicated products like Mint or Monarch for that individual's specific use case. Finance and health are identified as the two domains people most want to hold in a private data store, partly because cross-referencing otherwise siloed data (e.g., calendar entries against health metrics) allows an agent to produce context-aware explanations, such as attributing a weight increase to travel. A related architectural trend separates the personal "store of record" database from the agents operating on top of it, avoiding lock-in to any single agent or CRM provider.

4. Technical Insights

Several implementation-level findings merit direct attention. Supabase's acquisition of Turso, whose architecture is compatible with both SQLite and Postgres, created a lightweight "Spark" tier for prototype-scale workloads, complementing Multigres for scale-up demand under a "prototype to petabytes" strategy. This dual-tier approach is a direct response to a scale projection with no historical precedent: extrapolating ChatGPT's roughly 1.2 billion weekly active users to agent-driven project creation implies on the order of 1.2 billion databases per month, a volume existing single-tier architectures were not designed to absorb.

Internally, Supabase's own engineering organization saw AI-authored code rise from roughly 10% to 60% of commits within six months, without a formal AI adoption policy - attributed to engineer trust in the pace of underlying model capability growth rather than mandated process change. This self-reported trend is consistent with the broader thesis but should be treated as an internal, unverified anecdote rather than an audited metric.

A separate technical architecture, described as "G Brain," illustrates how Postgres-based retrieval scales for personal-agent use cases. It combines pg_vector retrieval with graph-structured querying, sitting between raw markdown files and a 1-million-token context window. The source identifies roughly 30-40GB of personal data as the threshold at which flat markdown retrieval becomes insufficient and Postgres plus pg_vector plus graph-style querying becomes necessary, with use cases scaling toward 300GB. An associated evaluation repository, "G Brain Evals," tracks roughly 40 categories covering retrieval efficiency, cost efficiency, and latency, generated from production traces rather than synthetic benchmarks. Most noteworthy is the use of autonomous "captain" agent loops that continuously generate new eval categories, research retrieval improvements, and auto-ship changes to the production branch - described in the source as a narrow, task-specific form of recursive self-improvement. This claim warrants caution: the term RSI typically denotes open-ended capability gain, and the described system appears bounded to a specific retrieval-optimization loop rather than general self-improvement.

5. Discussion

The data suggest that infrastructure providers face a bifurcated design problem: building simultaneously for machine consumers that value inspectability, scriptability, and actionable error semantics, and for human non-engineer consumers who require low-friction entry points absent any CLI expertise. Supabase's response - pursuing both ends through Spark/Turso and Multigres - suggests that serving one audience well no longer excuses neglecting the other, since both populations may route through the same underlying agent.

The economic implications documented align with this shift. Vertical SaaS founders reaching $5-10M ARR are reported to struggle with Series A fundraising despite that threshold having reliably attracted capital 9-12 months prior, while other founders reach $10-15M (and in some cases $25-50M) ARR with 10-15 person teams, driven by AI-enabled leverage. At roughly $2M ARR per head and 50% margins, such teams can be profitable without external capital, which the source frames as producing a psychological shift among founders - profitability without fundraising increasingly supplants fundraising success as the marker of achievement. This is a notable but anecdotal observation that would benefit from systematic data across a larger founder sample before being treated as a general market trend.

An open question concerns durability of the non-engineer builder segment: whether domain-expert-built software (the taxi-driver example) persists as production infrastructure or remains a one-off prototype is not addressed in the source material and merits further empirical tracking.

6. Conclusion

The central contribution of this analysis is evidentiary: a major infrastructure platform now reports a majority of new activity originating from autonomous agents rather than humans, and this shift is measurable in concrete telemetry - sign-up growth, database creation rate, and revenue growth - rather than being merely anecdotal. The practical takeaway for infrastructure builders is that agent-facing design (open-source inspectability, actionable error messages, code-first interfaces, model-specific evals) and non-engineer-facing design (low-friction builder tooling) are not mutually exclusive investments but increasingly converge through the same agent intermediary. Organizations building developer infrastructure should treat agent tool-selection behavior, rather than human UX preference alone, as a first-class design input going forward.

Sources

• What Happens When Everyone Can Build Software - Original Creator (YouTube)
• Analysis and summary by Sean Weldon using AI-assisted research tools

About the Author

Sean Weldon is an AI engineer and systems architect specializing in autonomous systems, agentic workflows, and applied machine learning. He builds production AI systems that automate complex business operations.

LinkedIn | Website | GitHub