A developer found your library on GitHub. Forty-three stars, active commits, exactly the feature they needed. They cloned it, read the README: “A fast, flexible framework for data processing.” Two sentences on installation. Nothing on configuration. No examples, no output, no indication of what “flexible” even meant in practice. They spent ninety minutes trying to get the simplest case to work, then found a competing library with fewer features and a three-step quickstart that actually ran. They used that one.
Your library never got a second chance.
That sequence plays out across every programming language and tool category, every day. The cost is invisible on the developer’s side: they just moved on. But on your side it compounds. Every user who abandons during the documentation phase is a user who never integrates, never recommends, never contributes, and never becomes the person who answers someone else’s question about your library on Stack Overflow.
Bad documentation raises support costs directly. Support engineers answer the same questions repeatedly because users can’t find the answers themselves. At some point the support team starts producing informal documentation in ticket responses, Slack threads, and internal wikis that nobody outside the team can access. This shadow documentation is part of the real cost: not just the tickets, but the knowledge that never reaches the people who need it.
For sales-driven software, the effect appears in the sales cycle. Prospects who can’t self-serve answers during evaluation ask more questions, demand more demos, and take longer to close. A well-documented product shortens that cycle. A poorly documented one lengthens it and sometimes ends it: the prospect assumes that if the documentation is this hard to navigate, the product probably is too.
Stripe is the counterexample most cited in developer circles — not for the API, but for the documentation. You can integrate their payment processing without filing a ticket, without emailing support, without digging through GitHub issues. Their docs get you to a first successful charge without friction. The support cost that doesn’t exist is the support cost that never needed to exist.
The inverse is just as instructive. When a developer abandons an SDK because the README has no examples, that’s a lost integration. When a user hits an error message with no explanation and no documentation link, that’s a support ticket. When a company buys software and the onboarding guide hasn’t been updated since version 2, that’s a contract risk.
The cost of bad documentation almost never appears on a budget line. It appears in support team headcount, in conversion rates, in churn, in the GitHub star count of a competing project that took documentation seriously. These costs are real. They’re just distributed across teams and timelines in ways that make them easy to miss until they’re hard to fix.
Write the docs first. Or at least: write them before the support queue tells you to.