diff --git a/src/content/blog/technical/developer-experience-documentation.mdx b/src/content/blog/technical/developer-experience-documentation.mdx
new file mode 100644
index 000000000..4ebe0f933
--- /dev/null
+++ b/src/content/blog/technical/developer-experience-documentation.mdx
@@ -0,0 +1,99 @@
+---
+title: 'Developer Experience Documentation: Why Accuracy Matters More Than Completeness'
+subtitle: Published July 2026
+description: >-
+  Developer experience docs set your API's first impression and activation rate. Most teams ship them once and stop. Here's why accuracy after launch is the real DX lever.
+date: '2026-07-30T00:00:00.000Z'
+author: Frances
+tag: Technical
+section: Use Cases
+hidden: false
+---
+import BlogNewsletterCTA from '@components/site/BlogNewsletterCTA.astro';
+import BlogRequestDemo from '@components/site/BlogRequestDemo.astro';
+
+A developer lands on your quickstart, copies the code sample, and runs it. It fails, because the authentication format changed four months ago and the quickstart never caught up.
+
+They check the reference docs. The endpoint is there, and the parameters look right, but the call still fails. Fifteen minutes in, they open a competitor's docs.
+
+Your documentation lost this developer. It told them something that used to be true.
+
+## Documentation is the developer experience
+
+Developer experience covers everything from onboarding to production. It includes SDKs, CLIs, tooling, support channels, and community. Most developers encounter the docs first.
+
+Before writing a single line of code, a developer reads the quickstart, skims the reference, and looks for a tutorial that matches their use case. That reading experience is the product demo for most API evaluations.
+
+Most teams treat documentation as a support resource, something that reduces tickets and helps existing users. That framing is too narrow. Your docs are the interface developers use to decide whether to adopt your product at all.
+
+[Postman's 2024 State of the API survey](https://www.postman.com/state-of-api/2024) found that 44% of developers dig through source code to understand an API because the documentation didn't give them what they needed. These developers found the docs and read them. The docs failed them anyway.
+
+## Time to first call is the metric most teams skip
+
+The clearest signal of DX documentation quality is time to first successful API call. This measures how long a new developer takes, starting from your landing page, to make a working request.
+
+Teams with strong DX documentation get this number below ten minutes. Developers who can't make a successful call within ten minutes have a measurably higher abandonment rate. The drop-off is steep. Every minute beyond that threshold increases the chance a developer gives up.
+
+Most teams don't measure this. They track documentation volume instead, the count of pages published and words written. Or they track documentation coverage, the count of endpoints documented and parameters described. Those metrics tell you whether docs exist. They don't tell you whether the docs work.
+
+The gap matters because completeness and accuracy are different problems. A complete doc set can still be wrong. A doc that covers every endpoint is still actively harmful if it describes those endpoints inaccurately.
+
+[Research from DX Index](https://getdx.com/blog/developer-documentation/) found that each one-point improvement in documentation quality score saves 13 minutes per developer per week. That number measures internal productivity. The same effect applies to external adoption. Accurate docs that get developers to their first success faster convert more of them into active users.
+
+## Developers already distrust your docs
+
+The accuracy problem is hard because developers don't trust documentation by default.
+
+Only 3% of engineers fully trust their documentation repositories. This figure comes from research across engineering teams. It reflects a rational response built from experience. Developers have been burned by stale docs before, so they have learned to verify everything.
+
+This is the trust deficit. Developers read your docs while keeping the source code or community forum open, ready to check facts. When docs are accurate, this habit costs little. When docs are wrong, a skeptical developer hits one error and loses confidence fast.
+
+The consequence is silent abandonment. [Research estimates](https://userguiding.com/blog/user-onboarding-statistics) that around 50% of developers abandon an API when documentation fails them. They leave without filing a support ticket that explains why. You must measure activation rate and trace drop-off back to specific documentation failures to see this happening.
+
+73% of development teams struggle with documentation that developers actually use. The 27% that get it right see 40% faster onboarding and 35% fewer support tickets. The gap between those groups is documentation accuracy maintained over time.
+
+<BlogNewsletterCTA />
+
+## AI agents amplify the cost of stale docs
+
+In 2025, a stale doc page misleads one developer at a time. In 2026, it misleads every developer using any AI tool that indexed your documentation.
+
+Coding agents such as Cursor, Claude Code, and GitHub Copilot read developer documentation as part of their context. A developer asks the agent how to authenticate against the Acme API. The agent finds your authentication guide, reads it, and answers from what it finds. If that guide references a deprecated token format, the agent generates code using the deprecated format. The developer gets a confident, wrong answer with no warning that anything is off.
+
+The same pattern appears in [agent context file maintenance](/blog/technical/agent-context-files-explained). Agents do not flag when they work from stale information. They reason forward from whatever they retrieved. A wrong premise in step two becomes the foundation for every step after.
+
+The damage spreads wider than it looks. A single outdated page in your developer docs spreads its wrong information to every AI-assisted developer who asks a related question. The wrong answer gets served the same way across tools until someone traces the error back to the source.
+
+Good DX documentation has the opposite effect. Accurate, well-structured docs reach more developers through agents than through search alone. Agents that find the right information give correct answers on the first try. Developers who get correct answers on the first try keep building.
+
+## Accuracy after launch is the actual problem
+
+Most DX documentation programs are launch-oriented. A team publishes docs when the API ships, and the docs are accurate at that moment. Then the product evolves.
+
+Endpoints get deprecated, parameters get renamed, authentication flows get updated, and SDK versions change. The docs don't update automatically. Someone has to notice each change and decide to update the relevant pages.
+
+In practice, this surveillance work fails at scale. Engineers who ship changes know the docs need updating but move on to the next ticket. Documentation owners who don't write the code have to discover changes by watching pull requests or waiting for a support ticket that traces back to a stale page. [Documentation drift](/blog/technical/documentation-drift-detection-problem) is a detection problem. The writing is easy once someone knows what changed.
+
+The teams that keep their DX documentation accurate have converged on a few structural fixes.
+
+Every page needs a named owner. This is one specific person whose job includes updating the page when the underlying feature changes. Pages without a named owner drift until someone notices the damage.
+
+Review triggers are the second piece. Documentation updates belong in the same pull request as the code change. When an endpoint is deprecated, the relevant docs get updated in that same commit, immediately.
+
+The third fix is automation. Manual surveillance, meaning someone watches pull requests, attends standups, and waits for support tickets, doesn't scale past a certain codebase size. Teams that stay ahead of drift use tooling that detects when documentation no longer matches the product. This catches the problem before a developer hits the discrepancy.
+
+The last point is where most programs fall short. Quarterly audits and documentation sprints catch some drift, but they miss the gaps that open between audits. The [changelog communication problem](/blog/technical/api-changelog-best-practices) applies here too. Knowing that a change happened is not enough on its own. The downstream documentation must catch up as well.
+
+## What DX docs need to be
+
+Developer experience documentation works best as a product.
+
+A product has an owner, and it gets updated when the underlying system changes. Teams measure a product by whether it works. Documentation that follows this model gets maintained like a product.
+
+The barrier to this shift is usually organizational. Documentation gets owned by a team that is not in the loop when product changes ship. Fixing this requires both process changes and tooling changes. Teams need clear triggers that tell them which change should start a doc review. Teams also need visibility into which pages have gone stale, without reading every page to find out.
+
+Both problems are solvable. Teams that solve them have documentation their developers trust. That trust shows up in activation rates and support volume. It also shows up in the quality of answers AI agents give on a company's behalf.
+
+Promptless monitors your documentation against your actual product and codebase. It flags what's outdated before a developer or their agent runs into it. The same mechanism keeps your API reference accurate. It also keeps your quickstarts and tutorials accurate. Both fail the same way when the product moves on without them.
+
+<BlogRequestDemo />