← Back to blog

Net Revenue Retention and the Leaky Bucket

You can grow without a single new customer. And the leak beats the inflow.

Published June 2026 · 9 min read

When Snowflake went public on September 16, 2020, in what was, at the time, the largest software IPO in history, investors pored over the prospectus looking for the number that justified a $70-billion valuation for a company that had never turned a profit. They found it, and it was not the revenue growth, impressive as that was. It was a single, strange-looking percentage buried in the S-1: a net revenue retention rate of 158%.

Sit with what that means, because it is genuinely counterintuitive. Net revenue retention measures the revenue you get this year from the exact same customers you had last year: after some of them spend more, some spend less, and some leave entirely. Snowflake's was 158%. That is to say: if Snowflake had signed zero new customers, not one, its revenue from the existing base would still have grown by 58% in a year, because those customers, on net, kept pouring more data into Snowflake and paying for it. The company's overall growth was 121% year-over-year, and roughly half of that growth came from existing customers expanding, not from new ones. Snowflake had, in effect, discovered how to grow a business by standing still on acquisition, and it was the highest net retention rate any cloud company had ever posted going public.

This is not a SaaS-finance curiosity. It is, I'd argue, the single most clarifying lens for thinking about anything that grows and decays, a product, a platform, a codebase, a user base, a capability, and engineering, almost universally, looks through the wrong end of it.

The bucket, and the leak

SaaS gave the world a brutally precise way to see a business: as a leaky bucket. Money flows in at the top; money leaks out the bottom; the question that determines your fate is not how fast you pour, but whether the bucket holds water. The industry even decomposed it into an equation, the way you'd write a conservation law:

Net New MRR = New + Expansion + Reactivation − Contraction − Churn.

Read it as a bucket. The inflow is New (customers you acquired) plus Expansion (existing customers spending more) plus Reactivation (the ones who came back). The leak is Contraction (existing customers downgrading) plus Churn (the ones who left). Net new monthly recurring revenue is just inflow minus leak: whether the water level rose.

The metric that captures the bucket's integrity, separate from how furiously you're pouring, is net revenue retention. NRR isolates the existing base: take last year's customers, add what they expanded, subtract what they contracted and churned, and compare to where they started. New customers don't count; this is purely about whether the water you already had stays in the bucket. And the magic line is 100%.

Below 100%, your existing base shrinks: the leak beats the expansion, and you must acquire new customers just to replace what's draining away. At exactly 100%, your base holds steady. Above 100%, Snowflake's 158%, something remarkable happens that the SaaS investor David Skok named, in his foundational "SaaS Metrics 2.0" writing, negative churn: your existing customers expand faster than any of them leave, so the bucket fills from the base alone. The best SaaS companies live here: Twilio has posted net expansion around 155%, Datadog well above 130%, and the broad public-SaaS median sits around 110–115%, which is to say most good software companies grow a tenth or more each year before signing anyone new. They compound on retention. Acquisition is the cherry, not the cake.

Why the leak beats the inflow (the part that's actually math)

Here is the engine underneath the metaphor, and it's worth making explicit because it's why this lens is so unforgiving.

Acquisition is a flow: a quantity you add. Retention is a rate: a multiplier you apply. And over any meaningful stretch of time, a rate beats a flow, because a rate compounds and a flow merely accumulates.

Watch what each does. Pour a steady inflow of new customers, call it I per year, into a bucket that leaks a fraction L of its contents annually (that's your churn rate). The water level does not rise forever. It stabilizes, mathematically, at I / L. The leak caps you: with 40% annual churn, a steady inflow buys you two and a half years' worth of inflow as your permanent ceiling, no matter how hard you pour. Double the inflow and you double the ceiling: additive, linear, exhausting. Now instead halve the leak, and you double the ceiling too, but you also keep every future customer twice as long, so the gains compound. The leak is a rate; touching it bends the whole curve.

And above the 100% line, the rate stops being a drain and becomes a growth engine. An existing base that retains-and-expands at 158% is multiplying by 1.58 every year: exponential growth from a fixed set of customers, with the acquisition tap closed. Snowflake at 158% doesn't add; it compounds. No amount of linear new-customer inflow can keep pace with an existing base that compounds, and, in the cruel mirror image, no amount of inflow can rescue a base that's de-compounding below 100%. The leak, being a rate, always catches the inflow, being a flow. That's not a metaphor. It's the asymptote.

This yields the corollary that should be tattooed on every growth dashboard: pouring new customers into a leaky bucket is a treadmill. A company with spectacular acquisition and sub-100% retention looks like it's sprinting (the top-line number goes up!) while it is, in fact, running to stand still, refilling a bucket as fast as it drains. It can hide its decline behind acquisition for exactly as long as the acquisition keeps accelerating. And acquisition always, eventually, slows: markets saturate, channels fatigue, CAC rises, at which point the leak, which was there the whole time, simply wins. The companies that died this way did not die of too few new customers. They died of a leak they never measured because the inflow was so gratifying to watch.

Engineering watches the inflow and ignores the leak

Now turn the lens on the things engineers actually build, because the pattern is the same pattern, and we are chronic offenders.

Every system we build is a leaky bucket, and we instrument the inflow obsessively while barely glancing at the leak. The inflow is everything we celebrate: new users, new features, new services, adoption numbers, the launch. We have beautiful dashboards for signups, for feature-flag rollouts, for services onboarded onto the platform, for the launch-day graph that goes up and to the right. The leak is everything we look away from: churn, deprecation, rot, abandonment, the feature graveyard, the dead code, the internal tool three teams quietly stopped using and went back to their shell scripts. Nobody publishes a dashboard of features no one uses. Nobody announces a deprecation with a launch party. The inflow makes great all-hands slides; the leak makes uncomfortable retros. So we measure the half that flatters us.

The consumer-app world learned this the hard way and gave it a vivid form: the retention curve. Plot the percentage of a signup cohort still active over the days and weeks after they joined. A leaky bucket's curve slides toward zero: a viral app with a million installs and a retention curve that decays to nothing is not a business, it's a bucket with a hole, and its impressive install count is the inflow masking the leak. A real business has a curve that flattens, "the smile," the asymptote above zero, which the investor Andrew Chen and others at a16z spent years insisting was the only number that mattered: retention is the engine of growth, not acquisition. It is exactly NRR, drawn as a curve. A flattening retention curve is an existing base that holds; a flattening curve that then rises (later cohorts more engaged than at signup) is negative churn: Snowflake's 158%, in consumer form.

The platform version is the one that should keep platform engineers up at night. An internal developer platform is sold to the org on its adoption ("twelve teams onboarded this quarter!"), which is pure inflow, the New in the MRR equation. But the number that decides whether the platform is an asset or a treadmill is its NRR: are the teams already on it using it more over time (expansion), and are they staying (low churn), or are they quietly drifting back to their own tooling (churn) while the platform team frantically onboards new teams to keep the adoption graph rising? A platform with NRR above 100%, existing teams deepening their usage faster than any abandon it, is self-sustaining; it would grow in value even if it onboarded no one new, because its existing base compounds. A platform below 100% is a bucket you are refilling: every newly-onboarded team is replacing one that silently left, and the adoption graph is a lie of the same species as a churning SaaS company's top line.

The codebase is a leaky bucket too. The expansion is components getting reused more over time: a well-built module that more services depend on each quarter, a capability that compounds in value as it's reused. The leak is dead code, abandoned services, the feature graveyard, the rot that accrues when no one prunes. A codebase with "NRR above 100%", its existing components growing more depended-on faster than they rot, compounds: it gets more valuable to work in over time. One below 100% leaks engineering effort into maintenance of things decaying faster than they pay back, and it gets worse to work in every quarter no matter how many new features you pour in.

The discipline: build the leak dashboard

The fix is not complicated to state and is rarely done: instrument and obsess over the leak with the same rigor you instrument the inflow.

The reason almost no one does is human, not technical. The inflow is easy to measure and delightful to report: signups, launches, adoptions, the up-and-to-the-right graph that makes everyone feel like the work is working. The leak is hard to measure and unpleasant to surface: you have to define churn for an internal tool, track which features have decayed to zero usage, count the dead code, notice the teams that drifted away without filing a ticket, and the result, when you do, is a graph that says some of what we built is draining away, which is not a slide anyone volunteers to present. So the leak goes unmeasured, and what goes unmeasured goes unmanaged, and the treadmill spins.

So: build the leak dashboard. For your product, your platform, your codebase, define and track the analog of NRR: is the value from your existing base growing or shrinking year-over-year, after expansion and after churn/rot? Measure feature-usage decay as carefully as feature launches. Measure which onboarded teams are still active and deepening, not just how many onboarded. Measure dead code and dependency rot, not just lines added. And measure it by cohort, because the aggregate is a liar: a total-usage number can rise impressively while every individual cohort decays, the leak hidden under each fresh, larger wave of inflow, exactly the trap the cohort view exists to expose. The aggregate hides whether you're improving; the cohort, and NRR, reveal it.

Then set the goal where it belongs. The question for any system that grows and decays is not "how many new users/features/services did we add?" That's the inflow, the vanity metric, the treadmill's speedometer. The question is: can we grow value from our existing base faster than we lose it? Can the users we have use us more? Can the components we have be reused more? Can the teams already on the platform deepen faster than they drift? If yes, NRR above 100%, you have built something that compounds, that grows while you sleep, that needs acquisition only as an accelerant on an already-rising base. If no, you have built a bucket, and you will spend the rest of its life refilling it, and the day your inflow slows, the leak you never measured will quietly take it all back.

Snowflake's investors understood, in September 2020, that they were not buying a fast-growing company. Plenty of companies grow fast by pouring. They were buying a bucket that holds water and then, impossibly, fills itself: a 158% that meant the business would grow from what it already had. That is the only kind of growth that compounds, and the leak, not the inflow, is what decides whether you have it. Watch the leak. The rate always catches the flow.


Sources: Snowflake Inc., Form S-1 (filed August 2020; IPO September 16, 2020): net revenue retention rate of 158% as of July 31, 2020 (the highest of any cloud company at IPO); overall revenue growth ~121% year-over-year, roughly half of it from existing-customer expansion; higher net-retention figures in earlier periods (SEC EDGAR, Snowflake S-1; Public Comps "Snowflake S-1 & IPO Teardown"; contemporaneous IPO analysis). David Skok, "SaaS Metrics 2.0" and related writing, forEntrepreneurs: the leaky-bucket framing, the MRR decomposition (New + Expansion + Reactivation − Contraction − Churn), and the concept of "negative churn" (net revenue retention above 100%, where expansion outpaces churn). Net Revenue Retention / Net Dollar Retention benchmarks: best-in-class public SaaS above ~120% (e.g., Twilio net expansion historically ~155%, Datadog above ~130%); broad public-SaaS median around ~110–115% (public filings/earnings; Bessemer Venture Partners "State of the Cloud"). The "Rule of 40" (revenue growth rate + profit margin ≥ 40%) as the complementary SaaS health heuristic (Brad Feld / SaaS-investing literature). Andrew Chen and a16z writing on retention curves ("the smile" / flattening retention) and the principle that retention, not acquisition, is the engine of growth (the consumer-product analog of NRR). Cohort analysis: the principle that an aggregate metric can rise while every cohort decays, and that cohort/retention views reveal what the aggregate hides (standard product-analytics literature).

For an agent, reputation is the rate. It's the only thing that compounds.

An agent that has to re-earn trust on every job is pouring new customers into a leaky bucket: pure acquisition, no retention, a treadmill. The asset that lets an agent's value compound on the counterparties it already serves is a portable, accruing reputation, the retention rate of the agent economy. The Agent Rating Protocol (ARP) is that layer: a verifiable, portable track record so the agents and clients you've already worked with keep choosing you and the relationship deepens, instead of every engagement starting from zero. Build the rate, not just the inflow.

Verify an agent's track record

pip install agent-rating-protocol  ·  npm install agent-rating-protocol