docs: correct unsourced and misattributed statistics across published blog posts

src/content/blog/technical/api-changelog-best-practices.mdx

@@ -2,7 +2,7 @@
 title: 'API Changelog Best Practices: Write for the Developer, Not the Team'
 subtitle: Published April 2026
 description: >-
-  68% of developers cite outdated API docs as their top frustration. Most changelogs cause it. Here's how to write one developers can actually use.
+  39% of developers say inconsistent documentation is the biggest roadblock to API collaboration. Most changelogs cause it. Here's how to write one developers can actually use.
 date: '2026-04-24T00:00:00.000Z'
 author: Frances
 tag: Technical
@@ -16,7 +16,7 @@ A developer reads your changelog. They see "Updated authentication flow." They o
 
 That sequence plays out thousands of times across API ecosystems. The changelog announced the change, but the reference docs haven't caught up. The developer can't use either one to move forward.
 
-The [Postman 2024 State of the API report](https://www.postman.com/state-of-api/2024), which surveyed over 5,600 developers and API professionals, found that 68% of developers cite outdated documentation as their top frustration when working with APIs. 39% say inconsistent documentation is the biggest onboarding roadblock. Those numbers don't reflect teams that never wrote documentation. They reflect teams whose documentation described a previous version of the product.
+The [Postman 2024 State of the API report](https://www.postman.com/state-of-api/2024), which surveyed over 5,600 developers and API professionals, found that 39% of developers say inconsistent documentation is the biggest roadblock to API collaboration. That number doesn't reflect teams that never wrote documentation. It reflects teams whose documentation described a previous version of the product.
 
 ## What most changelogs get wrong
 
@@ -86,7 +86,7 @@ The purpose of an API changelog is to help developers answer whether a change re
 
 A changelog designed around that question separates breaking from non-breaking changes, gives deprecation notices specific dates, links to updated reference documentation, and ships the docs with the release. A changelog designed as an internal record doesn't answer that question at all.
 
-Most of that 68% had documentation to read. The frustration comes from documentation that seemed accurate and turned out not to be. A changelog entry that announces a change alongside reference docs that still describe the old behavior is the most common source of that frustration.
+Most of that 39% had documentation to read. The frustration comes from documentation that seemed accurate and turned out not to be. A changelog entry that announces a change alongside reference docs that still describe the old behavior is the most common source of that frustration.
 
 [Keeping reference docs synchronized with what ships](https://promptless.ai/blog/technical/how-teams-keep-docs-up-to-date-with-promptless) is the work that makes the changelog credible. [Documentation drift detection](https://promptless.ai/blog/technical/documentation-drift-detection-problem) catches the gap between a changelog entry and the reference pages that should reflect it, before the next developer hits the inconsistency.
 

src/content/blog/technical/developer-documentation-roi.mdx

@@ -20,9 +20,9 @@ This is the wrong metric. Support ticket deflection is real, but it captures a s
 
 Stack Overflow's developer survey found that developers spend more than 30 minutes per day searching for solutions to technical problems. Separate research puts the figure higher, with half of developers losing roughly 10 hours per week sourcing basic information they need to do their jobs. They are senior-engineer hours paid at full rate, spent compensating for an information system that should have made the answer obvious.
 
-Research on developer experience makes this concrete. The DXI framework from DX (formerly DX Data) measures documentation quality as its own dimension of developer experience. Their data finds that each 1-point improvement in documentation quality saves 13 minutes per developer per week. For a 100-person engineering team, a 5-point improvement translates to 5,000 hours per year, roughly $500,000 in recovered capacity at a $150k average salary.
+Research on developer experience makes this concrete. The DXI framework from DX measures documentation quality as one of 14 drivers of developer experience. [DX's Developer Experience Index research](https://getdx.com/blog/guide-to-developer-experience-index/) finds that each one-point improvement in a team's overall DXI score saves 13 minutes per developer per week. For a 100-person engineering team, a 5-point improvement translates to 5,000 hours per year, roughly $500,000 in recovered capacity at a $150k average salary.
 
-The inverse calculation is equally useful. A team where documentation problems consume 15 to 25% of engineering capacity, a figure drawn from engineering surveys and [documented in our post on documentation drift](/blog/technical/documentation-drift-detection-problem), is effectively paying 15 to 25 engineers to compensate. Those engineers read source code instead of docs and ask Slack questions that a functioning information system would already answer. That is the cost denominator that rarely appears in a documentation business case.
+The inverse calculation is equally useful. A team where documentation problems consume 15 to 25% of engineering capacity, [an estimate DX documents](https://getdx.com/blog/developer-documentation/) for teams that run this kind of self-assessment, is effectively paying 15 to 25 engineers to compensate. Those engineers read source code instead of docs and ask Slack questions that a functioning information system would already answer. That is the cost denominator that rarely appears in a documentation business case.
 
 Support ticket deflection matters for customer-facing documentation. For internal and developer-facing docs, the engineering time lever is at minimum 10x larger.
 
@@ -42,7 +42,7 @@ Few documentation teams make this argument, because the causal chain is harder t
 
 ### 1. Developer experience surveys
 
-A single survey question asking developers to rate documentation quality on a scale of 1 to 10, tracked quarterly, is enough to build a trend line. Each point of improvement carries the 13-min/developer/week value above. For your specific team size and salary band, the dollar value is calculable and defensible.
+A single survey question asking developers to rate documentation quality on a scale of 1 to 10, tracked quarterly, is enough to build a trend line. Documentation is one of the drivers feeding the DXI score, where each point of improvement carries the 13-min/developer/week value above. For your specific team size and salary band, the dollar value is calculable and defensible.
 
 This is the most actionable metric for leadership conversations, because it is a number that moves and can be traced to investments. When you ship a documentation sprint, the DXI score should move. When it does not, that is also useful information.
 
@@ -76,7 +76,7 @@ The documentation ROI argument is strong, but it is only sustained by accuracy m
 
 The engineering time calculation is what closes most leadership conversations.
 
-Take your team size. Multiply by average salary. Multiply by 15%, which is the low end of engineering capacity lost to documentation problems. That is your annual cost denominator. Then estimate what a 5-point DXI improvement is worth at your team size, using the 13-min/week/developer figure. The gap between those two numbers is the available ROI and the investment case.
+Take your team size. Multiply by average salary. Multiply by 15%, the low end of DX's estimated range for engineering capacity lost to documentation problems. That is your annual cost denominator. Then estimate what a 5-point DXI improvement is worth at your team size, using the 13-min/developer/week figure. The gap between those two numbers is the available ROI and the investment case.
 
 Start with two tracking practices. First, run a quarterly developer survey with a single documentation quality question. Second, pull 50 escalated tickets and categorize them by root cause. Add a coverage metric against your product surface once those baselines exist. Together they convert "our docs need to be better" into a business case with a dollar value and a trend line.
 

src/content/blog/technical/documentation-coverage.mdx

@@ -47,7 +47,7 @@ The ownership gap explains the rest. Documentation coverage spans multiple teams
 
 The result is that most teams discover documentation coverage gaps reactively. A developer opens a support ticket asking how to use a feature that was never documented. The question surfaces in a Slack channel. A post appears on a forum. By then, the gap has already caused friction for at least one person and probably for many more who silently gave up.
 
-Research from GetDX estimates that documentation problems consume 15 to 25 percent of engineering capacity. That cost includes time developers spend searching for information and interrupting colleagues for answers. A significant share of that cost comes from features that shipped without documentation.
+DX, a developer-productivity vendor, estimates that documentation problems consume [15 to 25 percent of engineering capacity](https://getdx.com/blog/developer-documentation/). That cost includes time developers spend searching for information and interrupting colleagues for answers. A significant share of that cost comes from features that shipped without documentation.
 
 <BlogNewsletterCTA />
 

src/content/blog/technical/documentation-debt-accrues-where-your-team-cant-see-it.mdx

@@ -18,7 +18,7 @@ That is documentation debt collecting interest.
 
 Documentation debt is the accumulated gap between what your docs say and what your product actually does, plus the sections where docs don't exist at all. Teams accumulate it passively by shipping without updating reference pages and releasing new features before the quickstart catches up.
 
-The productivity cost inside your organization is real. Research consistently estimates that documentation problems consume 15 to 25% of total engineering capacity, as developers read source code instead of docs and ask Slack questions that accurate documentation would prevent. For a 100-person engineering team, that's the equivalent of 15 to 25 engineers whose time disappears into compensating for missing or inaccurate documentation. Annually, that translates to somewhere between $500,000 and $2 million in a mid-sized company.
+The productivity cost inside your organization is real. DX, a developer-productivity vendor, [estimates that documentation problems consume 15 to 25% of engineering capacity](https://getdx.com/blog/developer-documentation/), as developers read source code instead of docs and ask Slack questions that accurate documentation would prevent. For a 100-person engineering team, that's the equivalent of 15 to 25 engineers whose time disappears into compensating for missing or inaccurate documentation. Annually, that translates to somewhere between $500,000 and $2 million in a mid-sized company.
 
 But those numbers capture only what happens inside your organization. The higher cost sits outside it.
 
@@ -28,7 +28,7 @@ When code debt slows your engineers down, they show up to sprint planning and sa
 
 Documentation debt slows down the people trying to use your product. They don't show up in your standups. A developer who hits a broken quickstart doesn't file a support ticket and wait. Research consistently finds that [around 50% of developers abandon an API](https://userguiding.com/blog/user-onboarding-statistics) when documentation fails them, and the broken page stays up for the next developer who hits the same wall.
 
-The scale of this is not subtle. [Postman's 2024 State of the API report](https://www.postman.com/state-of-api/2024) found that 68% of developers cite outdated documentation as their top frustration when working with APIs. 78% of development teams report challenges with outdated or insufficient documentation. 64% of developers spend four or more hours per week searching for project information that should already be accessible.
+The scale of this is not subtle. [Postman's 2024 State of the API report](https://www.postman.com/state-of-api/2024) found that 39% of developers say inconsistent documentation is the biggest roadblock to API collaboration. 78% of development teams report challenges with outdated or insufficient documentation. 64% of developers spend four or more hours per week searching for project information that should already be accessible.
 
 What makes documentation debt durable is the gap between how much pain it causes and how visible that pain is to the teams responsible for it. The people most affected are new developers and external integration partners, and they have no seat at the table when backlog priorities get set.
 

src/content/blog/technical/documentation-debt.mdx

@@ -38,7 +38,7 @@ Documentation debt concentrates in three areas.
 
 **Support volume.** Outdated API references and incorrect setup guides generate support tickets at scale. Each ticket consumes the customer's time, the support engineer's time, and often the context-switch overhead of a developer pulled in for escalation.
 
-**Engineering interruptions.** Every time a developer answers a question that should be in the docs, they lose 15-20 minutes recovering their working context. Research consistently estimates this compounds to [15-25% of total engineering capacity](https://promptless.ai/blog/technical/documentation-drift-detection-problem) in teams with significant documentation debt. That's 15-25 engineers per 100-person team spending their time compensating for missing documentation instead of building.
+**Engineering interruptions.** Every time a developer answers a question that should be in the docs, they lose 15-20 minutes recovering their working context. DX, a developer-productivity vendor, [estimates this compounds to 15-25% of engineering capacity](https://getdx.com/blog/developer-documentation/) in teams with significant documentation debt. That's 15-25 engineers per 100-person team spending their time compensating for missing documentation instead of building.
 
 <BlogNewsletterCTA />
 
@@ -64,7 +64,7 @@ Ownership matters just as much. Documentation without a named owner gets updated
 
 Some teams embed documentation review into the PR process itself. When a PR touches a public API endpoint, it triggers a review of the corresponding reference doc. When a config file changes, the setup guide gets flagged. Automated checks at the point of change are the same mechanic that makes code debt visible.
 
-The [teams that keep docs current](https://promptless.ai/blog/technical/how-teams-keep-docs-up-to-date-with-promptless) build systems that surface what needs updating before it becomes a problem. Understanding [why documentation drift is a detection problem](/blog/technical/documentation-drift-detection-problem) gives you the specific failure modes to build prevention around.
+The [teams that keep docs current](https://promptless.ai/blog/technical/how-teams-keep-docs-up-to-date-with-promptless) build systems that surface what needs updating before it becomes a problem. Understanding [why getting-started guides drift after launch](https://promptless.ai/blog/technical/sdk-documentation-best-practices-after-launch) gives you the specific failure modes to build prevention around.
 
 ## The measurement gap is the starting point
 

src/content/blog/technical/documentation-drift-detection-problem.mdx

@@ -16,7 +16,7 @@ Right now, somewhere in your docs, there is a lie.
 
 It's not malicious. It was accurate when it was written. But a parameter was renamed, an endpoint was deprecated, a flow was quietly restructured — and no one updated the page. The lie has been sitting there for weeks, maybe months, misleading developers who trust it.
 
-This is documentation drift: the slow, continuous divergence between what your docs say and what your product actually does. According to a Postman survey, 68% of developers cite outdated documentation as their top frustration when working with APIs. A 2025 IEEE review of the field confirmed what practitioners already know: "Maintaining alignment between software code and specifications is a persistent challenge in the software development lifecycle."
+This is documentation drift: the slow, continuous divergence between what your docs say and what your product actually does. According to [Postman's 2025 State of the API report](https://www.postman.com/state-of-api/), 55% of respondents report struggling with inconsistent documentation. A 2025 IEEE review of the field confirmed what practitioners already know: "Maintaining alignment between software code and specifications is a persistent challenge in the software development lifecycle."
 
 The standard advice is to treat this as a writing problem. Audit quarterly. Add a docs-update field to your PR template. Hire another writer. Run a documentation sprint. None of these interventions are wrong — but they all miss the actual bottleneck: the problem is not the writing, it's the knowing.
 
@@ -28,7 +28,7 @@ Drift follows a predictable pattern at scale. A developer ships a change — a r
 
 Even when teams have a dedicated documentation owner, the shape of the problem shifts rather than disappearing. Now the writer has to discover the change — by watching Slack, scanning pull requests, attending standups, or waiting for a support ticket that turns out to be an outdated doc. This is surveillance work: constant, manual, and impossible to sustain as codebases and teams scale.
 
-The downstream costs are significant. A simple diagnostic — surveying developers on documentation quality, tracking Slack questions, measuring PR cycle time — typically finds that documentation problems consume **15–25% of total engineering capacity**. Not because people aren't writing, but because they're compensating: reading source code instead of reading docs, asking questions on Slack that docs should answer, debugging integration issues that trace back to an outdated spec. That's 15–25 engineers per 100-person team doing work that accurate documentation would eliminate.
+The downstream costs are significant. DX, a developer-productivity vendor, recommends a simple diagnostic — surveying developers on documentation quality, tracking Slack questions, measuring PR cycle time — and [estimates it typically surfaces documentation problems consuming 15–25% of engineering capacity](https://getdx.com/blog/developer-documentation/). Not because people aren't writing, but because they're compensating: reading source code instead of reading docs, asking questions on Slack that docs should answer, debugging integration issues that trace back to an outdated spec. That's 15–25 engineers per 100-person team doing work that accurate documentation would eliminate.
 
 And 75% of APIs don't conform to their own specifications, according to a recent report on API drift — not because teams don't care, but because the tooling and processes for detecting drift haven't kept pace with the speed of development.
 

src/content/blog/technical/how-to-measure-developer-documentation-roi.mdx

@@ -59,7 +59,7 @@ Most ROI analysis treats documentation as a one-time investment with a fixed ret
 
 The more accurate question is whether the return is holding over time, and whether the gap between the product and the documentation is widening.
 
-[Developer-facing documentation](/blog/technical/developer-documentation-roi) tends to have the steepest decay curve. It receives the most developer traffic, covers the most product-specific detail, and changes fastest as the product evolves. It is the highest-return documentation to get right, and the highest-cost documentation to let go stale.
+Developer onboarding documentation tends to have the steepest decay curve. It receives the most developer traffic, covers the most product-specific detail, and changes fastest as the product evolves. It is the highest-return documentation to get right, and the highest-cost documentation to let go stale.
 
 Teams that measure documentation ROI well watch the current return and the maintenance state at the same time, tracking TTFC, activation rate, and support volume alongside how far the docs have drifted from the actual product. Neither tells the full story alone. Both together distinguish documentation quality problems from documentation decay problems, which have different causes and different fixes.