{
  "title": "The Beat — deep dives",
  "updated": "2026-08-06",
  "count": 4,
  "deep-dives": [
    {
      "id": "2026-08-06-the-deprecation-that-didnt-burn-anyone",
      "title": "The deprecation that didn't burn anyone",
      "date": "2026-08-06",
      "summary": "Five sunsets landed in six weeks — on clocks of 27 days, 29 days, a month, ten months, and twelve months. The window is what gets quoted, but the mechanics decide who gets burned. A working anatomy of the clean deprecation, and the checklist for running one as the campaign it is.",
      "dek": "GitHub retired three surfaces in a week. MCP put a year under everything it deprecated. HashiCorp published a ten-month calendar. Cerebras' free-tier sunset lands August 17. The migration window is the headline — but notice reach, loud failure, and where the export lands are what separate a clean deprecation from a quiet churn event.",
      "tags": [
        "dx",
        "activation",
        "positioning"
      ],
      "sources": [
        {
          "label": "Model Context Protocol — The 2026-07-28 Specification",
          "url": "https://blog.modelcontextprotocol.io/posts/2026-07-28/"
        },
        {
          "label": "GitHub Changelog — GitHub Models is being fully retired on July 30 (July 1)",
          "url": "https://github.blog/changelog/2026-07-01-github-models-is-being-fully-retired-on-july-30-2026/"
        },
        {
          "label": "GitHub Changelog — GitHub Models is now retired (July 30)",
          "url": "https://github.blog/changelog/2026-07-30-github-models-is-now-retired"
        },
        {
          "label": "GitHub Changelog — Upcoming deprecation of GitHub Spark (August 4)",
          "url": "https://github.blog/changelog/2026-08-04-upcoming-deprecation-of-github-spark-on-github-com/"
        },
        {
          "label": "HashiCorp Developer — HCP Vagrant Registry end of life",
          "url": "https://developer.hashicorp.com/hcp/docs/vagrant/hcp-vagrant-eol"
        },
        {
          "label": "Hacker News — Cerebras discontinue its free tier plan",
          "url": "https://news.ycombinator.com/item?id=48941271"
        },
        {
          "label": "Ian L. Paterson — Free LLM APIs in 2026",
          "url": "https://ianlpaterson.com/blog/free-llm-api-2026/"
        },
        {
          "label": "Stripe — APIs as infrastructure: future-proofing Stripe with versioning",
          "url": "https://stripe.com/blog/api-versioning"
        },
        {
          "label": "Kubernetes — Deprecation policy",
          "url": "https://kubernetes.io/docs/reference/using-api/deprecation-policy/"
        },
        {
          "label": "Heroku — Heroku's Next Chapter (2022 free-tier sunset)",
          "url": "https://www.heroku.com/blog/next-chapter"
        }
      ],
      "url": "https://thebeat.dev/deep-dives/2026-08-06-the-deprecation-that-didnt-burn-anyone/",
      "markdown_url": "https://thebeat.dev/deep-dives/2026-08-06-the-deprecation-that-didnt-burn-anyone.md",
      "body": "Developer marketing has a whole literature on launches and almost none on endings. That gap just became expensive, because the last six weeks produced five dated sunsets from four vendors, and they read like a controlled experiment in how to end a product:\n\n- **MCP** deprecated its old transport, its old auth registration, and three protocol features on **July 28** — with a written, minimum **twelve-month** offramp under all of it.\n- **GitHub Models** went dark on **July 30** — six weeks after it closed to new customers, and **29 days** after existing customers were told the shutdown date.\n- **GitHub Spark** was deprecated on **August 4** — new users and new apps stopped that day; existing users get until **August 31**, about **27 days**, to export.\n- **HashiCorp's HCP Vagrant Registry** got a three-phase calendar ending **June 7, 2027** — roughly **ten months** of runway from the August 3 announcement.\n- **Cerebras'** free API tier converts to a credit-based model on **August 17** — about a month after the email went out.\n\n[The W31 weekly](/issues/2026-W31) made the short version of the argument: the migration window is a positioning claim now, the way the pricing cap became one. This dive is the long version, and it complicates the headline number. The window is what gets quoted, but it is not what determines who gets burned. **A deprecation is a campaign — the last one you will ever run for that product, and the first impression for everything else you sell.** Like any campaign it has mechanics: whether the notice reaches the person whose code will break, whether failure is loud before it is fatal, whether the export lands somewhere the customer controls, and whether the replacement is named honestly. Get those right and even a short window can be survivable. Get them wrong and a twelve-month window is just a longer fuse on the same churn event.\n\n## Why the damage is silent\n\nStart with what a botched deprecation actually costs, because it is systematically underpriced — the feedback loop is broken.\n\nWhen a launch flops, you see it: no signups, no upvotes, a quiet Slack. When a deprecation burns someone, you mostly see nothing. The developer whose cron job started failing at 3 a.m. does not file an angry ticket; they patch around you, note \"this vendor breaks things,\" and surface that judgment months later at the next build-vs-buy decision — a meeting you are not in. [The DX section of the guide](/guide/04-developer-experience-and-activation) has carried this point since July; the five cases let us put mechanics under it.\n\nThe cleanest specimen of the silent burn predates all five windows. In a dated write-up of running production workloads on free LLM APIs, practitioner Ian Paterson describes Cerebras quietly pruning its free-tier model catalog from about a dozen models down to two — by May 31 the live API returned exactly two entries. His monitoring script, pinned to one model name, failed every call. \"No email, no deprecation notice that reached me,\" he writes. \"One day the call worked, the next it returned a 404.\" The error did not even say *deprecated* — it said the model \"does not exist or you do not have access to it.\" (His account is single-sourced; the two-model catalog was checkable against the live API at the time.)\n\nNote what that episode is not: it is not a pricing controversy, and it never trended. It is one developer, one broken integration, one conclusion filed away — repeated across however many integrators were pinned to those models. That is the quiet churn event. No spike in any dashboard, and the trust is gone anyway. The reason to study deprecation mechanics is that this failure mode is *invisible by default*, so only deliberate process prevents it.\n\n## What the long window buys — and what it actually consists of\n\nThe [2026-07-28 MCP spec](https://blog.modelcontextprotocol.io/posts/2026-07-28/) is the current benchmark, and it is worth being precise about why — because the twelve months is the least interesting part.\n\nThe spec deprecated real, deployed surface: the legacy HTTP+SSE transport, Dynamic Client Registration, and the Roots/Sampling/Logging features. Each deprecation is tracked under a numbered proposal (SEPs), dated, and covered by an explicit keep-working guarantee: \"They still work, and they'll keep working for at least twelve months. New implementations shouldn't adopt them.\" The window is framed as a design goal — \"a twelve-month minimum window so you can plan upgrades instead of reacting to them\" — and the offramp shipped *with* the deprecation, not after it: all four Tier-1 SDKs (TypeScript, Python, Go, C#) supported the new spec day one, with migration notes on the breaking changes. The project even concedes the cost out loud: \"there will be some migration cost, especially for developers that did depend on session identifiers.\"\n\nDecompose that and you get four mechanics, only one of which is the number: a **dated policy** (not a promise made per-incident), a **keep-working guarantee** with a floor, a **migration path that exists on day one**, and **honesty about the cost**. [HashiCorp's Vagrant retirement](https://developer.hashicorp.com/hcp/docs/vagrant/hcp-vagrant-eol) shows the same anatomy stretched over infrastructure: three dated phases (new box creation ends 2026-12-14, support ends 2027-03-15, operations cease 2027-06-07), promised export tooling — local export, S3 hosting guidance, \"a snapshot of all existing Vagrant boxes\" in \"a static archive with URL redirects\" — and the open-source community edition named as the fallback, with the honest caveat that users will \"be responsible for the hosting costs incurred.\" Ten months is shorter than MCP's twelve-month floor, but the load-bearing part isn't the total — it's that every phase has a date and the exit ramp is specified before the first door closes.\n\nNeither of these invented the pattern. The institutional ancestors are policies, not events. [Stripe's 2017 versioning post](https://stripe.com/blog/api-versioning) described date-pinned API versions with the claim that \"we've maintained compatibility with every version of our API since the company's inception in 2011\" — nearly a hundred backwards-incompatible changes without ever forcing an upgrade — and framed the whole thing in one sentence developer marketers should tattoo somewhere: \"Just like a power company shouldn't change its voltage every two years, we believe that our users should be able to trust that a web API will be as stable as possible.\" [Kubernetes' deprecation policy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/) puts hard floors in writing — GA API versions \"must not be removed within a major version\"; beta versions keep being served for at least nine months or three releases after deprecation — and, since v1.19, makes the API itself announce the deprecation via a `Warning` header and a metric.\n\nThat last mechanism matters more than it looks. A published policy converts every individual deprecation from a judgment call into a contract lookup — the integrator can price the risk before adopting. That is why \"what's your deprecation policy\" is quietly becoming a procurement question, and why the window has migrated from an ops detail to a positioning surface.\n\n## The anatomy of the short one\n\nNow the counterexamples — and the honest reading is more mixed than \"GitHub bad.\"\n\n[GitHub Models' retirement](https://github.blog/changelog/2026-07-30-github-models-is-now-retired) got some mechanics genuinely right. The shutdown was staged: closed to new customers June 16, full retirement [announced July 1](https://github.blog/changelog/2026-07-01-github-models-is-being-fully-retired-on-july-30-2026/), dead July 30. And crucially, the July 1 notice scheduled two **brownouts** — July 16 and 23 — during which \"GitHub Models requests will temporarily return errors before service is restored.\" A brownout is the loud-failure pattern done properly: it finds the integrations whose owners never read the email, in a way that is recoverable. It exists precisely because notice sent is not notice received. Any team running a shutdown should copy it.\n\nWhat Models got wrong is everything around the clock. Existing customers — explicitly including those \"with active usage\" — got 29 days from the announced hard date to errors. There was no export tooling and no like-for-like replacement: departing users were pointed at Microsoft Foundry (\"a broad model catalog\") and Copilot — adjacent products with different auth, different billing, different shapes. The killed product's core value was being the zero-setup way to call models with just a GitHub token; neither successor preserves it. Compare Heroku's 2022 free-tier sunset — the canonical modern precedent — which gave roughly three months from [announcement](https://www.heroku.com/blog/next-chapter) (August 25) to shutdown (November 28) and at least stated its reason plainly: \"an extraordinary amount of effort to manage fraud and abuse.\" Heroku's sunset is remembered bitterly anyway, which is the point — three months and a named reason is roughly the *floor* at which a free-tier kill stays merely unpopular. Models came in well under it.\n\n[Spark](https://github.blog/changelog/2026-08-04-upcoming-deprecation-of-github-spark-on-github-com/), announced five days later, is the strangest case: brutal clock, decent mechanics. About 27 days to the August 31 export deadline — the shortest window in this comparison — but the export lands somewhere the developer controls (the workbench's \"Create repository\" flow puts the app's code in a normal GitHub repo), and \"apps you've already deployed will continue to work after GitHub Spark is retired.\"\n\nExcept many won't — and this is the finding that generalizes. Spark apps call AI through a built-in `llm()` function. That function ran on GitHub Models, which died July 30. So every Spark app using AI broke *five days before Spark's own deprecation was announced*, and the fix is to \"replace it with your own inference provider\" — your own API key, your own billing. Each window, judged alone, was administered roughly as documented. Stacked, the platform's dependency retired before the platform's users were told anything. Call it **compounding clocks**: a deprecation schedule is only as trustworthy as the schedules of everything underneath it, and the burn landed on people who never chose GitHub Models at all — they chose Spark, which chose Models. If you sell a platform, your deprecation policy implicitly includes your suppliers'.\n\n## The steelman: most windows are wasted on most users\n\nThe strongest case for the short window deserves stating properly, because parts of it are true.\n\nFirst: migration is deadline-driven. Give integrators twelve months and most will move in month twelve — every ops team knows the migration curve is a hockey stick at the cutoff. The window's length mostly changes *when* the scramble happens, not whether it happens. Brownouts exist because even a dated email doesn't get read; arguably the brownout, not the window, does the real work of finding stragglers.\n\nSecond: long offramps have a real carrying cost. Stripe can afford eternal compatibility because it built version-transformation modules that make old versions a fixed cost; most teams didn't, and for them every deprecated-but-supported surface is an on-call burden, a security exposure, and a tax on velocity. Worse, a killed product has no team left to staff a ten-month wind-down — the org has already moved on, which is exactly why retired products get short clocks.\n\nThird: proportionality. GitHub Models was free, marketed to experimenters, never GA'd as critical infrastructure. Killing an experiment fast is what healthy portfolios do; demanding Kubernetes-grade process for every playground would mean fewer playgrounds shipped at all.\n\nAll fair — and all beside the point, because each argument prices the deprecation against *the product being killed*, and the trust damage lands on *everything else the vendor sells*. Developers cannot reliably distinguish the experiment from the platform ex ante — GitHub retired three surfaces in five days (Models, the Copilot Billing Preview app, and Spark), and the reader deciding today whether to build on any GitHub AI surface has exactly one usable signal about which of them is next: the vendor's demonstrated deprecation behavior. That is what a published policy is *for* — it is the mechanism that lets you kill experiments fast without repricing your platform, because it tells integrators in advance which one they are holding. The vendors with written floors (Stripe, Kubernetes, now MCP) are the ones that get to make aggressive changes without a trust bill. The absence of a policy means every sunset is adjudicated by vibes, and the vibes compound against you.\n\nAnd the deadline-driven-migration point cuts the other way: if most users move only at the cutoff regardless, then the *cost* of a long window to the vendor is mostly support overlap — while the cost of a short one is borne entirely by the minority with real production dependencies, who are precisely your most valuable integrators. The hockey stick is an argument for brownouts and loud failure, not for short windows.\n\n## Cerebras lands in eleven days\n\nWhich brings us to the live test. Per the notification email [quoted on Hacker News](https://news.ycombinator.com/item?id=48941271), on August 17 Cerebras free-tier accounts transition to a credit-based model: \"You'll be required to add a payment method to unlock $5 in free credits to continue to use the service.\" The notice went out by email roughly a month ahead — dated, explicit, and a defensible business change. Free tiers are not entitlements, and a payment-method gate is the standard fraud control; Heroku's entire sunset rationale was the abuse a naked free tier attracts.\n\nBut Cerebras is running this sunset with a trust deficit it already incurred — the silent catalog pruning above — and against a developer base predisposed to read it cynically (the HN thread's verdict, in one commenter's words: Wall Street demands growth, the freebies get taken away, time to pay for your tools). So August 17 is a clean natural experiment in whether mechanics can carry a sunset that sentiment is against. What clean looks like, concretely: requests after the cutoff fail with an error that names the change and links the migration doc — not a `404`, not \"model does not exist\"; the dashboard shows the credit state before the deadline, not after the first failed call; and the models in the catalog hold still through the transition, because a pricing change and a catalog change in the same window reads as bait-and-switch even when it's coincidence. If integrations die silently at 9:00 a.m. on the 17th, the episode goes in the churn-event column and the catalog pruning becomes a pattern instead of an incident. We'll log how it lands.\n\n## Running the ending as a campaign\n\nFor the reader who markets a developer product, the synthesis. You will eventually deprecate something — a free tier, an API version, an acquired product, a model. The five cases reduce to a checklist, in priority order:\n\n1. **Publish the policy before you need it.** A written floor — \"deprecated surfaces keep working N months minimum\" — is the single highest-leverage artifact, because it converts every future sunset from a judgment call into a contract lookup, and it is a sales asset the week a competitor botches theirs. MCP's twelve-month minimum is the current benchmark in the agent ecosystem; as of mid-2026, a window measured in weeks reads as a warning label on everything else you ship.\n2. **Date every phase.** Three dates minimum: announcement, freeze (no new usage), off. HashiCorp published all three at once, ten months out. An undated \"we plan to wind down\" is not a deprecation, it's a threat.\n3. **Make the API the channel.** The integration that breaks belongs to someone who does not read your email. Kubernetes returns a `Warning` header; GitHub Models ran two scheduled brownouts. Loud, recoverable failure before the cutoff is the only notice that reliably arrives. And the terminal error is marketing copy: it must say *deprecated*, name the date, and link the migration guide. A silent `404` is how you end up in someone's blog post as the cautionary tale.\n4. **Ship the offramp with the announcement, not after.** MCP's SDKs supported the new spec on day one; Spark's export was a working button, landing code in a repo the user owns. An export \"coming soon\" is a promise from a team that is being disbanded.\n5. **Name the replacement honestly — including \"there isn't one.\"** Pointing users at adjacent products as if they were substitutes (Models → Foundry/Copilot) insults the people who can tell the difference, which for developer products is all of them. If there is no like-for-like, say so, expect the churn, and plan the win-back instead of pretending.\n6. **Audit the compounding clocks.** If you sell a platform, list what your users' workloads transitively depend on and check those schedules against yours. Spark's users were burned by a deprecation two layers down, before their own notice existed.\n7. **Measure it like a campaign.** Notice reach, migration curve against the deadline, share migrated before the final week, support-ticket shape after cutoff. If you can't tell whether the notice arrived, you have decided not to know whether you burned anyone.\n\nThe through-line: a launch and a deprecation are the same discipline pointed in opposite directions. Both are dated, staged communication events with a funnel, a measurable outcome, and copy that does real work. The industry treats one as marketing and the other as an ops chore — and the vendors that have figured out it's all one trust surface are, not coincidentally, the ones whose deprecations don't make lists like this one.\n\nTwo dates to watch. August 17: how Cerebras lands. End of September: whether any devtool that ships an MCP server publishes a dated public migration plan off the deprecated transport and auth — the test [the W31 weekly](/issues/2026-W31) set. The first vendor to market its migration plan as a feature, rather than bury it as a chore, gets to own the positioning that this whole summer just made legible: *we end things well*."
    },
    {
      "id": "2026-07-30-four-numbers-that-survive-the-cfo",
      "title": "Four numbers that survive the CFO: what a developer motion should actually report",
      "date": "2026-07-30",
      "summary": "62% of DevRel teams now report to the C-suite, but only 18% can tie their work to revenue — and the vendors' own dashboards are starting to hand your CFO usage numbers whether you report them or not. The fix is four auditable numbers, each with a known cost to collect.",
      "dek": "DevRel has spent seven years arguing about whether it should be measured in money. Meanwhile the seller's dashboard started counting your empty seats, the signal vendors got acquired into GTM suites, and the field's own metrics working group went quiet. The argument is over — what's left is choosing numbers a finance team can re-derive.",
      "tags": [
        "devrel",
        "metrics",
        "measurement"
      ],
      "sources": [
        {
          "label": "Mary Thengvall — DevRel Qualified Leads (blog series, from December 2019)",
          "url": "https://www.marythengvall.com/blog/category/DevRel+Qualified+Leads"
        },
        {
          "label": "State of Developer Relations — 2024 report (11th annual)",
          "url": "https://www.stateofdeveloperrelations.com/2024devrelreport"
        },
        {
          "label": "devrel.agency — Announcing the 11th Annual State of Developer Relations Report (September 2024)",
          "url": "https://www.devrel.agency/post/announcing-the-11th-annual-state-of-developer-relations-report"
        },
        {
          "label": "Develocity — A look into the 10th Annual State of Developer Relations report",
          "url": "https://develocity.io/a-look-into-the-10th-annual-state-of-developer-relations-report/"
        },
        {
          "label": "swyx — DevRel's Death as Zero Interest Rate Phenomenon (dx.tips, early 2024)",
          "url": "https://dx.tips/zirp"
        },
        {
          "label": "Forecastable — Why your CFO distrusts partner-sourced pipeline",
          "url": "https://forecastable.com/partner-sourced-vs-partner-influenced/"
        },
        {
          "label": "GitHub Changelog — New Copilot usage metrics impact dashboard (2026-07-22)",
          "url": "https://github.blog/changelog/2026-07-22-new-copilot-usage-metrics-impact-dashboard/"
        },
        {
          "label": "Common Room — The 5 usage-based plays Otter.ai used to 2x outbound pipeline",
          "url": "https://www.commonroom.io/blog/otter-webinar-recap/"
        },
        {
          "label": "DevRel Foundation (Linux Foundation) — working groups",
          "url": "https://dev-rel.org/about/working-groups"
        },
        {
          "label": "DevRel Foundation — Metrics & Reporting working group (archived November 2025)",
          "url": "https://github.com/DevRel-Foundation/wg-metrics-reporting"
        },
        {
          "label": "HCLTech — Report exposes widening AI divide, only 18% of enterprises seeing revenue impact (July 2026)",
          "url": "https://www.hcltech.com/press-releases/hcltech-report-exposes-widening-ai-divide-only-18-enterprises-seeing-revenue-impact"
        }
      ],
      "url": "https://thebeat.dev/deep-dives/2026-07-30-four-numbers-that-survive-the-cfo/",
      "markdown_url": "https://thebeat.dev/deep-dives/2026-07-30-four-numbers-that-survive-the-cfo.md",
      "body": "Somewhere this quarter, a CFO is deciding whether the developer motion — the DevRel team, the developer-marketing budget, the community program — earns another year. The [2024 State of Developer Relations report](https://www.stateofdeveloperrelations.com/2024devrelreport) says 62% of DevRel teams now report to founders or C-level executives, 20% directly to the CEO. It also says only 18% tie their metrics to revenue influence, and 61% struggle to demonstrate impact. Read those three numbers together: the field won the org-chart argument and is still losing the budget argument, in the same room.\n\nThe thesis of this piece is one sentence: **report four numbers the finance team can re-derive from systems it already trusts — cost per activated developer, activated-to-revenue conversion, influenced pipeline under a written rule finance co-signed, and net revenue retention split by developer engagement — and move everything else to an appendix.** Each of the four has a knowable cost to collect. Reach, views, stars, and community warmth are real, and they are context, not currency. The currency is what survives an audit.\n\n## How the field got stuck\n\nThe measurement argument is older than most of the teams having it. The canonical early answer is Mary Thengvall's [DevRel Qualified Leads](https://www.marythengvall.com/blog/category/DevRel+Qualified+Leads), from December 2019: since DevRel keeps getting judged on other departments' metrics — signups for sales, badge scans for marketing — repurpose the \"qualified lead\" into something DevRel actually controls. A DQL is a person the team connects to the company who creates value anywhere: a community member who becomes a case study, a beta tester, a bug reporter, an integration partner, a hire, sometimes a customer. The framework's virtue is that it counts work DevRel uniquely does. Its limit, which matters for this piece, is that finance cannot price a bug report. DQLs are a good internal operations metric and a weak budget defense, because the person auditing the budget has no system of record where a DQL lives.\n\nThen came the correction. swyx's [DevRel's Death as Zero Interest Rate Phenomenon](https://dx.tips/zirp) is the essay of record on 2023–24: the 2020–2022 buildout was a ZIRP artifact, the contraction was a right-sizing, and — the sharper point — late-ZIRP DevRel had developed what he calls performative overaccountability — \"trying to instrument and measure every little youtube view and github star as though it matters.\" The Common Room survey he cites found 26% of DevRel respondents had experienced layoffs in 2023. The 2024 survey wave put layoffs at 15% and median total compensation at $193,000 — expensive people, still getting cut at meaningful rates, still mostly unable to show a revenue line.\n\nTwo details from the record say the field knows this is unresolved. In the 10th annual survey (2023), measurement was the top challenge in the field at 67.3% — ahead of awareness, ahead of burnout. And the [DevRel Foundation](https://dev-rel.org/about/working-groups) — the Linux Foundation project meant to standardize the discipline — had a dedicated [Metrics & Reporting working group](https://github.com/DevRel-Foundation/wg-metrics-reporting) that was archived in November 2025 with a one-line README: \"This working group is no longer active.\" The community-engagement and resources groups carried on. The field's own attempt to standardize its answer to the CFO went quiet first.\n\n## Why 2026 forces the issue\n\nYou could read seven years of stalemate as evidence the question is unanswerable. What changed is that other people started answering it for you, with your usage data.\n\nOn 2026-07-22, GitHub shipped a [Copilot impact dashboard](https://github.blog/changelog/2026-07-22-new-copilot-usage-metrics-impact-dashboard/) that sorts an enterprise's licensed users into adoption-phase cohorts — and breaks out a named \"Passive\" segment: licensed, paid for, unengaged. That is a vendor handing the buyer's finance team a shelfware count ([our coverage](/articles/2026-07-23-copilot-passive-seats)). The renewal conversation for every seat-based devtool is converging on the same shape: the CFO opens a dashboard someone else built and asks why 30% of the seats are dark. If the developer-facing team hasn't brought its own usage-linked numbers, it doesn't get to frame that conversation — it gets framed by it.\n\nThe same consolidation is happening one layer down. The tools that package community and product signals into revenue language keep getting acquired into GTM suites — Clari merged with Salesloft in a deal that closed December 2025, Apollo bought Pocus in March 2026, Zoom agreed to buy Common Room in July ([our coverage](/articles/2026-07-18-community-signal-rollup); all terms undisclosed). The market is betting real money that developer-behavior signals belong in the revenue stack. The operators already there agree: Otter.ai's growth team [described](https://www.commonroom.io/blog/otter-webinar-recap/) scoring outbound on roughly 80% behavioral signals to 20–30% firmographics and doubling outbound pipeline — a vendor-hosted account, so discount accordingly, but directionally consistent with everything else in this list.\n\nThe conclusion practitioners keep resisting: the question is no longer *whether* the developer motion gets measured in revenue terms. It's whether the numbers come from you, with definitions you wrote, or from someone else's dashboard.\n\n## The four numbers\n\nThe test for every candidate number is the same. Can the CFO re-derive it from a system finance already trusts — the warehouse, the CRM, the billing system? If yes, it's currency. If it lives only in your team's spreadsheet, it's a story. Stories are fine; they go in the appendix.\n\n### 1. Cost per activated developer\n\nTake the quarter's spend on the developer motion. Divide by the number of developers who reached your activation bar — not signups, the bar itself: first successful API call, first deploy, first workflow completed. (If you haven't defined that bar, that's the prerequisite work; [the time-to-value dive](/deep-dives/2026-07-06-time-to-value-is-the-growth-engine) is the anatomy.)\n\nThis is the top-of-funnel number finance actually wants from you. It's the developer-native analog of customer acquisition cost, and it's honest in a way \"cost per signup\" is not, because a signup that never calls the API is a vanity row. It also trends the right way when the team is doing real work: better docs, a faster quickstart, and sharper targeting all push it down.\n\n**Cost to collect:** a cross-team definition meeting and a few weeks of instrumentation — activation events flowing into the warehouse with stable identifiers. Ongoing cost near zero. **Failure mode:** definition drift. The bar quietly lowers so the number improves. Fix: the definition is written down, versioned, and changing it requires telling finance you changed it.\n\n### 2. Activated-to-revenue conversion\n\nOf the developers (or accounts) that activated in a cohort, what share reached production, paid, or a qualified opportunity within a stated window? This is the bridge number — it converts \"we activate developers\" from a leading-indicator claim into a demonstrated link to money. Reported by cohort, it also answers the question CFOs ask second: is the quality of what you bring in going up or down?\n\n**Cost to collect:** this is where identity resolution stops being a data-engineering footnote and becomes the tax. Product accounts, CRM records, and billing rows describe the same human three different ways; joining them is the whole job. It's also, not coincidentally, the pitch of every signal vendor that just got acquired — Common Room's own case material claims a customer cut duplicate records from 3% to 0.3% (vendor-claimed). Budget a real data-engineering investment the first quarter and a maintenance drip after. **Failure mode:** silently counting only the easy joins, which overstates conversion for exactly the segments you already understand.\n\n### 3. Influenced pipeline — under a rule finance co-signed\n\nHere's where most reports die, and the mechanics of why come from the partnerships world, where finance has seen this movie longest. [Forecastable's write-up](https://forecastable.com/partner-sourced-vs-partner-influenced/) on partner pipeline puts it in one line: \"A CFO will defend a partnerships investment that produces $3M in partner-sourced ARR with a defensible attribution rule. But a CFO won't defend a '$10M influenced' number\" — especially, it adds, when the influenced figure \"double-counts every deal an AE mentioned to a partner in passing.\" Swap \"partner\" for \"DevRel\" and every word holds. The moment finance audits one deal in your influenced number and finds a webinar attendance two months after the SDR sourced it, the entire figure — and next year's headcount ask — collapses with it.\n\nThe fix is not to abandon influence; it's to make the rule auditable and boring. Pick three or four *documented* touch types — a workshop a named buyer-side developer attended, a community thread your team resolved for someone on the account, a hands-on lab at an event with a badge scan. Write the rule down. Get sales ops and finance to sign it. Report influenced pipeline *only* under that rule, always separated from sourced (which will be smaller, and should be), and volunteer a quarterly audit: pull ten influenced deals at random, show the touches. An invited audit is the cheapest trust you will ever buy.\n\n**Cost to collect:** mostly political, not technical — CRM hygiene and the negotiation of the rule itself. Two months of nagging, then a habit. **Failure mode:** touch inflation. Every logged touch type you add makes the number bigger and less believable. The discipline is keeping the list short.\n\n### 4. Net revenue retention, split by developer engagement\n\nTake accounts with active developer usage — real engagement against your activation and usage bars — and accounts without. Report net revenue retention for each. If the developer motion works the way you claim, engaged accounts renew better and expand more, and the spread between those two NRR figures is the single most persuasive number in the whole report, because it's denominated in the CFO's own unit.\n\nThis is also the defensive number. GitHub's passive-seat cohort is this exact computation run from the seller's side; the [HCLTech/Raconteur survey wave](https://www.hcltech.com/press-releases/hcltech-report-exposes-widening-ai-divide-only-18-enterprises-seeing-revenue-impact) from the same week (500 enterprises, vendor-commissioned) had 90% of enterprises saying AI transforms workflows while only 18% see significant revenue impact — buyers are being armed to find the gap between paying and using. Computing your own engagement-split NRR means that when the passive-seat question arrives at *your* renewal, you answer with a number you've already reconciled, not a rebuttal you're improvising.\n\n**Cost to collect:** the most expensive of the four — it stacks on the identity join from number 2 and adds cohort work in the warehouse; realistically a quarter of part-time data-engineering effort before the first honest cut. **Failure mode:** confusing correlation with cause. Engaged accounts may retain better because healthy accounts engage. Say so in the footnote — a CFO trusts a team that flags its own confound far more than one that claims a clean causal line — and if you want the causal version, that's what holdouts are for.\n\n## The strongest case against — taken seriously\n\nThe counter-argument is not a strawman; it's the field's majority position, held by its most credible people. In the 10th annual survey, 88.7% of practitioners said sales activities are not part of DevRel. Thengvall built DQLs precisely because money-metrics imported from other departments were metrics DevRel \"has zero control over.\" And the failure the camp predicts is real and well documented: put a pipeline number on an advocate and the advocacy dies — developers smell capture instantly, and the trust that made the program work is the first casualty. [Our own guide](/guide/03-devrel-and-community) says a version of this: don't put a lead quota on DevRel.\n\nSteelmanned fully: *any* revenue reporting, however carefully fenced, becomes a target the moment budgets tighten — Goodhart's law with a org chart. The team that reports influenced pipeline in Q1 gets an influenced-pipeline *goal* in Q3, and by next year advocates are prioritizing accounts by deal size. If the numbers exist, they will eventually be used as quotas. The only safe move is not to create them.\n\nHere is why that position, held sincerely, keeps losing: the numbers get created anyway. The 2023–24 correction was not gentler on the teams that refused revenue framing; by swyx's account and the survey record, it hit them first, at 26% layoff exposure, while the field's median comp sat near $200K — a cost line that visible does not get to opt out of a language the CFO understands. And 2026's twist is that abstention no longer even keeps the numbers from existing: the seller's dashboard, the acquired signal vendors, and the buyer's own procurement team are all computing usage-to-revenue numbers about your motion. Refusing to report is no longer refusing to be measured. It's just refusing to be present when the measuring happens.\n\nThe honest synthesis: the quota objection is an argument about *individual* incentives, and it's correct at that level. Never put pipeline goals on a named advocate; measure people on the craft — content shipped, questions answered, feedback landed in the roadmap. But the *program* — the budget line the CFO sees — must be reported in auditable currency, because that's the level where the alternative is someone else's dashboard. Report the program in money. Manage the people on craft. The failure mode isn't reporting revenue; it's collapsing the two levels into one.\n\n## What this looks like on one page\n\nThe report to finance is one page, quarterly:\n\n1. **Cost per activated developer** — trend, with the activation definition footnoted and versioned.\n2. **Activated-to-revenue conversion** — by cohort, window stated, join coverage stated (\"we can match 74% of product accounts to CRM; here's the plan for the rest\").\n3. **Influenced pipeline** — under the co-signed rule, sourced reported separately, audit standing invitation.\n4. **NRR split by engagement** — with the correlation caveat in print.\n\nThen one appendix page for everything the four numbers can't carry: reach, community health, product feedback shipped, the DQL stories. That material is real — it explains *why* the four numbers move — but it's evidence for the mechanism, not the mechanism's price.\n\nAnd one line at the bottom that costs nothing and buys more credibility than any figure: **what we stopped counting this quarter, and why.** A team that retires its own vanity metric in writing is making the exact move the whole report depends on — showing finance it would rather have a smaller true number than a bigger soft one. That is, in the end, the entire trade: the four numbers are smaller than the story you could tell. They're also the only ones still standing after the audit."
    },
    {
      "id": "2026-07-17-geo-for-devtools-when-the-reader-is-a-model",
      "title": "GEO for devtools: what to do when the reader is a model",
      "date": "2026-07-17",
      "summary": "Machine-mediated discovery is real — Vercel gets 10% of signups from ChatGPT — but most of what's sold as GEO is ritual. The work that pays is docs and API surfaces you should want anyway.",
      "dek": "A $1B monitoring unicorn, a file 97% of crawlers never read, and a registrar that lets an agent buy a domain — the machine-reader thread finally has enough evidence to sort into \"do now,\" \"design for,\" and \"don't buy yet.\"",
      "tags": [
        "docs",
        "channels",
        "distribution"
      ],
      "sources": [
        {
          "label": "GEO: Generative Engine Optimization (Aggarwal et al., KDD 2024)",
          "url": "https://arxiv.org/abs/2311.09735"
        },
        {
          "label": "The llms.txt proposal (Jeremy Howard, September 2024)",
          "url": "https://llmstxt.org/"
        },
        {
          "label": "Ahrefs — We analyzed 137K sites: 97% of llms.txt files never get read (June 2026)",
          "url": "https://ahrefs.com/blog/llmstxt-study/"
        },
        {
          "label": "Search Engine Journal — Google says llms.txt is purely speculative for now (June 2026)",
          "url": "https://www.searchenginejournal.com/google-says-llms-txt-is-purely-speculative-for-now/577576/"
        },
        {
          "label": "Search Engine Journal — Google's llms.txt guidance depends on which product you ask (2025)",
          "url": "https://www.searchenginejournal.com/googles-llms-txt-guidance-depends-on-which-product-you-ask/575431/"
        },
        {
          "label": "Cloudflare — The crawl before the fall of referrals (July 2025)",
          "url": "https://blog.cloudflare.com/ai-search-crawl-refer-ratio-on-radar/"
        },
        {
          "label": "Cloudflare — The crawl-to-click gap: AI bots, training, and referrals (August 2025)",
          "url": "https://blog.cloudflare.com/crawlers-click-ai-bots-training/"
        },
        {
          "label": "Guillermo Rauch — ChatGPT now refers 10% of new Vercel signups (April 2025)",
          "url": "https://x.com/rauchg/status/1910093634445422639"
        },
        {
          "label": "Guillermo Rauch — ChatGPT referred under 1% of Vercel signups six months earlier (February 2025)",
          "url": "https://x.com/rauchg/status/1898122330653835656"
        },
        {
          "label": "Similarweb — Gen AI stats and AI visibility trends (May 2026)",
          "url": "https://www.similarweb.com/blog/marketing/geo/gen-ai-stats/"
        },
        {
          "label": "Fortune — Profound raises $96M at a $1B valuation (February 2026)",
          "url": "https://fortune.com/2026/02/24/exclusive-as-ai-threatens-search-profound-raises-96-million-to-help-brands-stay-visible/"
        },
        {
          "label": "GoDaddy — Introducing the GoDaddy Developer Platform (July 2026)",
          "url": "https://www.godaddy.com/resources/news/introducing-the-godaddy-developer-platform-domain-apis-for-developers-and-their-agents"
        },
        {
          "label": "OpenBenchmarks — verified benchmarks for agents",
          "url": "https://openbenchmarks.com"
        },
        {
          "label": "Crawlie — SEO and GEO monitoring with an MCP endpoint",
          "url": "https://www.crawlie.co/"
        },
        {
          "label": "Ian Paterson — Free LLM API Tiers in 2026: Groq, Cerebras, Mistral & More",
          "url": "https://ianlpaterson.com/blog/free-llm-api-2026/"
        }
      ],
      "url": "https://thebeat.dev/deep-dives/2026-07-17-geo-for-devtools-when-the-reader-is-a-model/",
      "markdown_url": "https://thebeat.dev/deep-dives/2026-07-17-geo-for-devtools-when-the-reader-is-a-model.md",
      "body": "A developer's first impression of your product is increasingly a paraphrase. A coding assistant summarizes your docs inside the editor. An answer engine compares you to two competitors in a chat window. And as of this month, an agent can go further than reading: GoDaddy's new developer platform is built so an agent can quote, register, and pay for a domain end to end. The reader of your marketing is, more and more often, a model.\n\nAn industry has formed around this fact almost overnight, and it has a name — `GEO`, generative engine optimization — a venture-funded tooling category, and a growing pile of rituals. It also has a loud counter-camp that says the whole thing is repackaged SEO snake oil, and the counter-camp is holding some genuinely damning data.\n\nBoth camps are right about different layers. The thesis of this piece: **machine-mediated discovery is a real channel with real conversion numbers, but almost everything sold under the GEO label is either premature or free — the durable work is making your docs and API surfaces machine-legible, which is work you should want anyway.** Sorting the layers is the whole job. So let's sort them.\n\n## How we got here\n\nThe term is younger than it feels. \"Generative Engine Optimization\" comes from a Princeton-led paper ([Aggarwal et al., KDD 2024](https://arxiv.org/abs/2311.09735), first posted November 2023) that asked whether content changes could improve a source's visibility in AI-generated answers. The headline finding — visibility gains \"up to 40%\" from tactics like adding quotable statistics and citations — is the number every GEO vendor deck has cited since. Keep its context: it was measured on `GEO-bench`, a research benchmark, and the paper itself warns the effect varies widely by domain. It is a lab result, not a field result.\n\nThe second artifact arrived in September 2024, when Jeremy Howard of Answer.AI proposed [llms.txt](https://llmstxt.org/): a curated markdown index at your site root, pitched as a way to hand context-window-limited models \"brief background information, guidance, and links to detailed markdown files.\" It cost an afternoon to ship, so devtool companies shipped it in droves — Anthropic, Stripe, Cursor, and thousands more.\n\nThen the money arrived. [Profound](https://fortune.com/2026/02/24/exclusive-as-ai-threatens-search-profound-raises-96-million-to-help-brands-stay-visible/), a platform that monitors how brands appear in AI answers, raised a $35M Series B led by Sequoia in August 2025 and a $96M Series C at a $1B valuation in February 2026 — 700+ enterprise customers, including MongoDB and Figma, about 18 months after launch. At the other end of the market, this month's Show HN pages carried [Crawlie](https://www.crawlie.co/) ($19/month, GEO checks plus an MCP endpoint so your agent can run the audit) and [OpenBenchmarks](https://openbenchmarks.com) (externally verified API benchmarks served to agents over an unauthenticated REST API and OpenAPI docs, plus an OAuth-gated MCP endpoint). A category that did not exist two years ago now spans from a unicorn to weekend projects.\n\nThat is the hype side of the ledger. The evidence side is messier, and more interesting.\n\n## What the skeptics can prove\n\nSteelman the counter-case properly, because parts of it are airtight.\n\n**Nobody reads llms.txt.** In June 2026, Ahrefs' Louise Linehan and Xibeijia Guan [checked all 137,210 domains](https://ahrefs.com/blog/llmstxt-study/) in Ahrefs Web Analytics that received traffic in May. About 28% had shipped a valid llms.txt — remarkable adoption for a two-year-old unofficial spec. But **97% of those files received zero requests** in the study period. Of the requests that did arrive, 96% were bots, and the biggest requester category was SEO audit tools (21.7%) — the industry checking its own homework. AI retrieval bots, the ones that would actually put you in an answer, were 1.1%. Most damning: AI bots made essentially zero requests for llms.txt files that *don't* exist, meaning they aren't even probing for it. Google's John Mueller said the quiet part in June: [\"it's purely speculative for now — the file has existed for years, yet none of the AI systems use it.\"](https://www.searchenginejournal.com/google-says-llms-txt-is-purely-speculative-for-now/577576/) That echoes what [Gary Illyes told a Search Central Live audience in 2025](https://www.searchenginejournal.com/googles-llms-txt-guidance-depends-on-which-product-you-ask/575431/): Google isn't pursuing llms.txt. The caveat this desk attached a week ago — \"no major provider has confirmed reading it\" — turns out to have been generous.\n\n**The traffic exchange is brutally lopsided.** Cloudflare's Radar data made the crawl-to-refer ratio a public metric in 2025: for every HTML page visit an AI platform referred back, [Anthropic's crawlers requested roughly 38,000 pages as of July 2025](https://blog.cloudflare.com/crawlers-click-ai-bots-training/) (down from an eye-watering 286,930:1 in January), OpenAI about 1,100:1, Perplexity about 195:1 — orders of magnitude from classic search economics, and trending in different directions by platform (Anthropic's ratio fell sharply from January to July 2025; Perplexity's roughly quadrupled over the same span). (Secondhand write-ups claim a specific, much-lower Claude ratio for May 2026; none traces to a source solid enough to print here, so treat any number more recent than Cloudflare's own August 2025 post as unverified.) And roughly 80% of AI crawler activity is model training, not answering a live user's question. If you expected AI platforms to replace the search traffic they're eroding, the data says no.\n\n**The measurement target moves.** Profound's own research — note the source: the vendor selling the fix — finds that [up to 90% of the sources cited in AI answers can shift over time](https://fortune.com/2026/02/24/exclusive-as-ai-threatens-search-profound-raises-96-million-to-help-brands-stay-visible/), and different models draw on largely distinct source sets. Whatever \"ranking\" you buy a dashboard to track is churning under you, per-model.\n\nSo: the flagship GEO artifact is unread, the traffic subsidy is a rounding error, and the metric is a moving target. Case closed?\n\n## What the skeptics can't explain away\n\nNo. Because the refutation targets the rituals, and the channel is not the rituals.\n\nThe cleanest devtool number belongs to Vercel. In April 2025, CEO Guillermo Rauch reported that [ChatGPT referred 10% of new Vercel signups](https://x.com/rauchg/status/1910093634445422639), up from [under 1% roughly six months earlier](https://x.com/rauchg/status/1898122330653835656) — his own attribution, on his own funnel. The mechanics behind it were mundane: Vercel made sure docs rendered as static HTML rather than client-side JavaScript, and structured content so a model could retrieve a clean answer to a task-shaped question. No llms.txt magic — plumbing.\n\nQuality data points the same direction. Similarweb's May 2026 read puts [ChatGPT referral conversion at 7.1%](https://www.similarweb.com/blog/marketing/geo/gen-ai-stats/) — second only to paid search at 7.8%, ahead of organic search, social, and email. AI referral *volume* is still small next to search, but it more than tripled between September 2024 and September 2025, and when ChatGPT made brand links clickable on May 7, 2026, pages per visit rose 24% and homepage referrals jumped to roughly 60% of its traffic — behavior that looks like *discovery*, not lookup. A visitor who arrives from an AI answer arrives pre-qualified: the model already matched your tool to their task and answered their first three objections.\n\nThe crawl-to-refer ratio, read again with marketer's eyes rather than publisher's eyes, isn't even bad news for you. A devtool company is not a news site; you don't sell pageviews. If a model ingests your docs ten thousand times to produce one perfectly-timed \"use X for this, here's the code\" in a developer's editor, you got the good end of that trade. The publishers subsidizing AI platforms with content have a real grievance. You have a distribution channel with a strange billing model.\n\nAnd the selection layer — agents not just reading about your product but transacting with it — stopped being hypothetical this month. [GoDaddy's Developer Platform](https://www.godaddy.com/resources/news/introducing-the-godaddy-developer-platform-domain-apis-for-developers-and-their-agents) (July 14) ships docs as markdown, a consolidated `llms-full.txt`, and OpenAPI — the quickstart literally opens with \"hand `domains-v3.json` to your LLM as context.\" Then it goes further than docs: a quote-then-execute purchase flow returns a short-expiry `quoteToken` at an exact price so an agent can't be surprise-billed; registration requires idempotency keys so a retry can't double-buy; consent objects record what was agreed and when; scoped tokens let an agent search domains without ever holding purchase permission. That is a marketing surface *and* a safety spec, and it's the most copyable artifact this thread has produced. OpenBenchmarks — six points on HN, but aimed squarely at agents making build-vs-buy calls — is the same bet from the other side: when the evaluator is a machine, verified numbers in machine-readable formats are the pitch.\n\n## The three layers, and what each is worth\n\nEverything above sorts into three layers with very different risk profiles.\n\n**The reading layer — real, cheap, act now.** Models already mediate first impressions; the Vercel case proves the funnel exists and your own analytics can prove your share of it. The work is unglamorous: serve docs as static HTML; make one section answer one question so a chunk retrieved alone still makes sense; put real numbers — pricing, limits, latency — on ungated pages where a model can quote them instead of guessing; publish OpenAPI for the reference; and check your `robots.txt` isn't blocking *retrieval* bots while you deliberate about *training* bots (Cloudflare's purpose breakdown shows those are different populations — you can decide the training question separately without silencing yourself in answers). Mueller's one non-speculative recommendation points here too: the optimization that matters most is not blocking the agents. Note what this list is: docs quality, honest pricing pages, accurate references. The machine reader raises the price of things developer marketing was already supposed to do.\n\n**The selection layer — early, design for it if you sell an API.** No one can show you conversion data on agent-initiated purchases yet; GoDaddy's platform is days old and OpenBenchmarks is a seedling. But the GoDaddy pattern — machine-readable everything, quote-then-execute, idempotency, scoped consent — is worth adopting *now* if agents plausibly transact with your product, because every element doubles as good API design for humans. This is DX engineering wearing a marketing hat. It also carries this thread's cautionary tale: weeks before GoDaddy launched, [a developer wrote up Cerebras quietly pruning its free-tier model catalog](https://ianlpaterson.com/blog/free-llm-api-2026/), breaking a hardcoded integration with a silent 404 instead of a deprecation notice. An agent that gets a clean, versioned deprecation notice reroutes; an agent that hits a silent 404 tells its developer your product is broken. Machine readers make loud deprecation a survival trait.\n\n**The measurement layer — forming, mostly don't buy yet.** The $155M invested in Profound says enterprises will pay to know how AI describes them, and at Fortune-500 scale, with hundreds of SKUs across ten AI surfaces, a dashboard may genuinely earn its keep. For a typical devtool company the honest math is different: citations churn up to 90%, each model reads different sources, and the free check gets you most of the signal — open three assistants, ask the task-shaped questions your buyers ask (\"how do I add auth to a Next.js app,\" not \"best auth provider\"), and record whether you appear, what's said about your pricing, and whether it's *true*. Do it monthly; it costs twenty minutes. Add an `ai-referral` segment in analytics and a free-text \"how did you hear about us\" field — Rauch's 10% figure came from exactly that kind of first-party attribution, not from a GEO platform. Buy tooling when the free check stops scaling, not before.\n\nAnd llms.txt? Ship it — it's an afternoon, it's cheap insurance if any provider ever flips it on, and its absence would be the wrong signal to the 21.7% of requesters that are audit tools your prospects might run. But the Ahrefs data closes the argument: expect nothing from it, and never let a checkbox file substitute for the underlying docs work, because today the checkbox is all it is.\n\n## The falsifiable version\n\nThe W28 issue of The Week made a call worth repeating with a date on it: by end of Q3 2026, at least one devtool company beyond Vercel publicly reports meaningful signups or API-key activations attributed to AI referral, with a number attached. The base rates say it should happen — conversion at 7.1%, volume tripling year over year. If nobody can produce that number by October, then the GEO category is running ahead of its market, and the reading-layer work — which pays for itself in human-legible docs regardless — remains the only part of this story you should fund.\n\nThat's the state of the art in one sentence: **treat the model as your most literal-minded reader — feed it clean structure and true numbers, design your API so its agents can transact safely, measure with the free checks, and keep your wallet closed until the dashboards can prove they know something your own funnel doesn't.**"
    },
    {
      "id": "2026-07-06-time-to-value-is-the-growth-engine",
      "title": "Time-to-value: the growth engine hiding in your onboarding",
      "date": "2026-07-06",
      "summary": "For a developer product, the minutes between install and first success predict adoption better than almost any campaign. Here's how to find that path, measure it, and pave it.",
      "dek": "Most developer-marketing budgets pour into the top of the funnel while the biggest leak sits in the first ten minutes of the product. This is where to look instead.",
      "tags": [
        "dx",
        "activation",
        "metrics"
      ],
      "sources": [
        {
          "label": "DevEx: What Actually Drives Productivity (Noda, Storey, Forsgren, Greiler — ACM Queue)",
          "url": "https://queue.acm.org/detail.cfm?id=3595878"
        },
        {
          "label": "DevEx in Action: A study of its tangible impacts (Forsgren et al. — ACM Queue)",
          "url": "https://queue.acm.org/detail.cfm?id=3639443"
        },
        {
          "label": "Draft.dev — Developer content as the cornerstone of product-led growth",
          "url": "https://draft.dev/learn/developer-content-the-cornerstone-of-product-led-growth"
        }
      ],
      "url": "https://thebeat.dev/deep-dives/2026-07-06-time-to-value-is-the-growth-engine/",
      "markdown_url": "https://thebeat.dev/deep-dives/2026-07-06-time-to-value-is-the-growth-engine.md",
      "body": "Ask a developer-marketing team where their funnel leaks and most will point at the top: not enough awareness, not enough traffic, not enough signups. Then look at the data and the biggest drop is almost always somewhere else — in the first ten minutes of actually using the product, between \"signed up\" and \"got something to work.\" That gap is **time-to-value**, and for a developer product it's the single most important thing marketing can influence.\n\n## Why the first ten minutes decide everything\n\nDevelopers evaluate by doing. A developer who reaches a real, self-produced success quickly — a returned query, a sent message, a deployed app — forms a belief that the product *works for them*. A developer who hits friction before that moment forms the opposite belief and leaves, usually without telling you why. Every downstream metric you care about — integration, retention, expansion, advocacy — is gated on getting through that first success.\n\nThis is why the industry frames documentation and onboarding as growth surfaces rather than support costs. The DevEx research literature makes the same point from the product side: reducing friction and shortening feedback loops is what actually drives developer productivity and satisfaction — and the same forces drive whether a developer sticks with *your* product at all.\n\n## Two numbers to instrument\n\nSeparate them; they leak differently:\n\n- **Time-to-first-success (TTFS)** — from landing on the quickstart to the first result the developer produced themselves. This is a *docs and onboarding* number.\n- **Time-to-value (TTV)** — from start to the first *useful* result, the thing they actually came to do. This is a *product* number.\n\nA great TTFS with a bad TTV means your quickstart dazzles and your product disappoints past \"hello world.\" A bad TTFS with a great TTV means the product is good but the on-ramp is broken — the most fixable and most common case in developer marketing.\n\n## Find the leak: map the path, instrument each step\n\nThe path to first success is a mini-funnel. For a typical API product it looks like:\n\n1. Land on quickstart\n2. Create account\n3. Generate an API key\n4. Set up the environment / install the SDK\n5. Make the first request\n6. See the first success\n\nInstrument every transition. The step with the steepest drop is your highest-leverage fix — and it's rarely the one you'd guess. Common culprits: an email verification wall before the first call, a signup form with too many required fields, an install that breaks on a common platform, or a first example that no longer runs.\n\n## Pave it\n\n- **Defer friction past first value.** Move verification, billing details, and profile fields to *after* the developer has seen something work. Every field before first success is a place to lose them.\n- **Make the golden path copy-paste.** One path, real runnable code, keys pre-filled in a sandbox where you can. Save the options and edge cases for the reference.\n- **Treat errors as onboarding.** An error message that says exactly what went wrong and how to fix it recovers developers you'd otherwise lose silently at the worst possible moment.\n- **Kill the second-day cliff.** A dazzling quickstart that dead-ends when they try something real just moves the drop-off. Pave the road from \"hello world\" to \"in production.\"\n- **Test it like a stranger.** Watch a developer who's never seen the product go from your homepage to first success. The friction is obvious in five minutes of observation and invisible in a dashboard.\n\n## Make it a shared scoreboard\n\nThe reason time-to-value is under-owned is that it sits between teams: marketing owns the traffic, docs owns the quickstart, product owns the API, engineering owns the errors. Put TTFS and activation rate on a scoreboard all of them share. When activation is falling, more top-of-funnel spend just pours water into a leaking bucket — and fixing the leak is almost always cheaper than buying more water."
    }
  ]
}