DocDrift

Idea

A continuous integration check that catches broken API docs before your developers do. DocDrift crawls a company's published developer docs (Mintlify, GitBook, ReadMe, Docusaurus, or plain Markdown/MDX in a GitHub repo), pulls out every code snippet in every tutorial and quickstart, and re-runs each one on a schedule against the company's own sandbox API. When a snippet's live response no longer matches what the surrounding prose claims (wrong status code, a field that's now required, a renamed parameter), it alerts the team in Slack with the failing page and a diff, before a developer hits it and bounces.

Market gap

Every API-docs tool today works at one of two layers, and neither one watches the layer that actually breaks. Layer one is the OpenAPI spec: tools like SpecShield (the successor to the now-dead Optic), Speakeasy, and Bump.sh diff spec versions and catch breaking changes in the contract itself. Layer two is docs hosting: Mintlify, ReadMe, GitBook, and Docusaurus publish the pages and, at best, offer an in-page "try it" console a human has to click. Nobody continuously executes the hand-written tutorial and quickstart code blocks, the parts of docs that live outside the spec (auth setup, multi-step walkthroughs, error handling), against the live API and tells you the moment they go stale.

The timing is right because two things just happened at once. First, "API documentation drift" became a named, discussed failure mode in the developer community through 2025 into 2026 (see Sources), meaning teams now have language for the problem but still no dedicated tool. Second, Optic, the one open-source project that was closest to this space, shut down in 2026, leaving API teams to migrate to spec-only successors that explicitly do not cover narrative docs content, per SpecShield's own migration guide.

Total Addressable Market (TAM)

Bottom-up, using only directly verified platform numbers:

• Mintlify has onboarded 10,000+ companies (source: Sacra, Mintlify revenue/funding profile). Mintlify positions itself specifically as documentation for API-first companies, so I count all 10,000 as in-market.
• GitBook has 30,000+ teams actively publishing docs (source: gitbook.com/customers). GitBook is used for far more than API docs (internal wikis, product manuals), so I assume conservatively that 20% of these teams maintain public API docs with runnable code samples: 6,000 companies.
• Combined target pool: 10,000 + 6,000 = 16,000 companies. This excludes ReadMe, Docusaurus (self-hosted), Redocly, and Stoplight customers entirely, so it understates the true pool.
• Blended ACV assumption: $3,000/year (a $250/mo average across the Starter and Growth tiers below; comparable self-serve dev-tool docs products like Mintlify itself price in the $150 to $300/mo band per Ferndesk's 2026 Mintlify review).
• TAM = 16,000 x $3,000 = $48M/year.
• SAM: assume 40% of that pool has both an active (not abandoned) public API and budget authority to add a third-party monitoring tool: 6,400 companies x $3,000 = $19.2M/year.
• SOM: a realistic 3-year target for a small team capturing roughly 1.5% of SAM: about 100 paying companies x $3,000 = $300K ARR, growing from there as the docs-testing category gets named and word of mouth compounds inside DevRel and platform-engineering circles.

Monetization strategy

Recurring SaaS subscription billed monthly or annually. The buyer is whoever owns developer experience: a DevRel lead, API platform engineer, or founding engineer at an API-first company. They keep paying because the product embeds itself into two habits: a Slack channel that pages them the moment a doc goes stale, and (on paid tiers) a GitHub Action that blocks or flags a docs PR when a snippet would break. Once it is part of the CI habit and the on-call rotation for docs, ripping it out means going back to finding out about broken docs from an angry developer instead.

Pricing strategy

• Starter: $99/mo - up to 50 monitored snippets, daily checks, Slack + email alerts, one docs source. Entry point for indie API startups and solo maintainers.
• Growth: $349/mo (anchor) - up to 300 monitored snippets, hourly checks, GitHub PR checks on docs changes, staging + production environments, priority Slack alerts. Sized for a small API platform team, the plan most customers land on.
• Scale: $999/mo - unlimited snippets, checks as often as every 5 minutes, multiple docs sites, SSO, dedicated support channel.

Lead magnet

A free, no-signup "Docs Health Scan": paste a docs site URL, DocDrift crawls it, extracts every code snippet, and statically checks each one for dead endpoints, deprecated auth patterns, and syntax that no longer matches the company's current OpenAPI spec (if public). It returns a shareable score card, like a Lighthouse or webpagetest.org report but for documentation, in under two minutes. Proves the product's core value (finding real breakage) before anyone creates an account, and captures an email to follow up about the scheduled, authenticated monitoring product.

Social proof that the problem exists

• Ask HN: The problem with current API documentation - active 2025/2026 Hacker News discussion of developers hitting stale, incomplete API docs, with commenters naming outdated code samples specifically as the trust-killer.
• Is outdated product documentation a known issue for you too? (Hacker News) - thread of practitioners confirming docs going stale is a recognized, shared pain across companies, not a one-off complaint.
• google-api-nodejs-client issue #352: "Having trouble with the Drive API quickstart" - a concrete GitHub issue from a real API provider (Google) where a user could not get the documented quickstart code sample to work because it had gone stale.
• OpenAI: Developer Experience Engineer job posting - a funded company hiring headcount specifically to build and maintain code samples and tutorials, evidence that keeping docs samples correct is expensive enough to warrant a dedicated role, i.e. willingness to pay to solve it another way.
• SpecShield: "Optic is dead" migration guide - shows the one open-source project closest to this space shut down in 2026, and its replacement explicitly scopes itself to OpenAPI spec diffing only, confirming the narrative-docs layer is uncovered by current tooling.

Competitors

• SpecShield (successor to Optic): OpenAPI spec diffing and breaking-change detection, CLI plus GitHub App, free tier plus paid from $29/mo. Works purely at the spec layer.
• Speakeasy: generates SDKs from an OpenAPI spec and runs contract tests between the SDK and the spec. Ensures the SDK matches the spec, not that a hand-written tutorial matches live behavior.
• Bump.sh: hosts docs from OpenAPI/AsyncAPI specs and diffs versions in CI. Strong at spec versioning, does not execute narrative code blocks.
• Mintlify, ReadMe, GitBook, Docusaurus: docs hosting and publishing platforms. Some (Mintlify, ReadMe) offer an interactive "try it" console a human clicks manually. None continuously execute the published tutorial snippets on a schedule.
• Postman (monitors/collections): can schedule API request checks, but only against collections a team builds and maintains separately in Postman, disconnected from the actual prose and code blocks published on the docs site.

What competitors offer now

Spec-first tools (SpecShield, Speakeasy, Bump.sh) are excellent at catching a removed field or a changed type the moment the OpenAPI spec changes, and they plug neatly into CI. But most narrative docs, the getting-started guide, the "how to handle pagination" tutorial, the multi-step auth walkthrough, are hand-written prose with code blocks that live outside the spec entirely, so none of these tools ever look at them. Docs hosts (Mintlify, ReadMe, GitBook) make the pages look good and, at best, let a human developer manually click "try it" on one endpoint at a time; they do nothing on a schedule and do not compare the response to what the paragraph above the code block actually promises. Postman monitors require a team to hand-build and hand-maintain a second copy of every check in Postman, which drifts from the docs just as fast as the docs drift from the API.

What can be done differently to attract customers

Point DocDrift at the docs site or GitHub repo the team already has (Mintlify, GitBook, ReadMe, Docusaurus, or raw MDX), zero migration, zero second source of truth to maintain. Use an LLM to read the prose around each code block and derive the actual claim being made ("returns 201 with an id field," "this parameter is optional"), then execute the snippet against the customer's sandbox and diff the real response against that claim, not just against a static schema. Ship the free, no-login Docs Health Scan as the wedge: any API company can see their own docs' rot in two minutes with no sales conversation, which spec-first tools never offer since they require an OpenAPI spec and Postman-style tools require setup before any value shows up.