Treat later releases as a cohort

Track the next nine production changes as one cohort. For each release, record:

  • why the change was requested;
  • elapsed and accountable human time;
  • review and test effort;
  • deployment and rollback effort;
  • incidents or support contacts within seven days;
  • recurring work introduced or removed; and
  • workflow value retained after thirty days.

This avoids a common analytical error: assigning the visible speed of the prototype to every future change while placing maintenance in an unmeasured bucket.

Garden's production lifecycle is one first-party example of release evidence that could feed this cohort: an exact source revision, private and live identities, failed releases, prior release lineage, and a separate code-rollback action. The page does not report the human time, incident load, or retained workflow value needed to establish better release economics.

Google's State of DevOps research provides a long-running framework around delivery throughput and stability. The framework is not a forecast for one small application, but it supports measuring speed together with failure and recovery rather than celebrating deployment frequency alone.

Separate four economic curves

Change demand asks whether useful requests decline as the workflow stabilizes or grow as adoption exposes more needs.

Verification cost asks whether tests and clear boundaries make each change safer, or whether accumulated coupling makes review progressively harder.

Incident load asks whether releases reduce operational work or create new alerts, support cases, recovery tasks, and dependency risk. Google's toil framework is useful here: manual, repetitive, reactive work that scales with service use is a real cost even when no vendor invoice names it.

Retained workflow value asks whether the application keeps saving time, reducing errors, or enabling revenue after the novelty of the first release.

Compare three possible shapes

An attractive curve has high initial learning, falling verification cost, stable incident load, and compounding workflow value. That suggests reusable operations and increasing knowledge of the domain.

A service-heavy curve has continuing customer-specific change demand and roughly linear human effort. It can support a sound business, but margins and venture scale depend on pricing and standardization rather than software abundance alone.

A trap curve has cheap creation followed by rising support, unclear ownership, and hard-to-reverse dependencies. The first release looked efficient because the business deferred costs into later periods.

Test the counterexample

Some applications genuinely need few later releases. A narrow calculator or stable data transformation may deliver value with little change. In that case the releases-two-through-ten test should not manufacture complexity.

The counter-test is elapsed time: track dependency updates, account changes, restore checks, user questions, and platform migrations even when product features do not change. A quiet repository is not necessarily a maintenance-free system.

Use a release cohort ledger

At release ten, calculate:

cost per retained improvement =
  total human and cash cost of releases 2–10
  / improvements still used after 30 days

Also report median lead time, change-failure count, recovery time, support contacts, and recurring hours added or removed. Do not force the result into a universal benchmark. Compare the cohort with its own release-one assumptions.

The thesis changes when later releases become cheaper to verify, easier to recover, and more valuable to users. Faster generation without those outcomes is production volume, not yet operating leverage.