Quantstruct

What do they actually do

Quantstruct scans product documentation to find problems like broken links, outdated steps, and drifting code examples, then uses AI to draft fixes. It focuses on catching staleness and mismatches early and packaging suggested changes so teams can merge them quickly.

Teams typically connect their docs repo or CMS, run scheduled or on‑demand scans, and receive findings with suggested edits. Results can be delivered as reviewable diffs or PRs and pushed into existing workflows (e.g., GitHub issues or Slack). The emphasis today is on safe, review-first changes rather than fully automatic updates.

Who are their target customer(s)

• Documentation engineers / writers: They spend significant time finding and fixing broken links, outdated steps, and style issues across many pages, and small, low-risk changes pile up behind long review cycles.
• SDK & developer-experience engineers: Code examples and API docs drift as libraries change, causing non-runnable or misleading examples that frustrate developers and slow releases.
• Support & customer-success reps: Outdated help articles generate repeat tickets and calls, and they lack clear data on which docs cause the most support load.
• Product managers & engineering managers: They can’t measure the impact of documentation drift on adoption or support costs, making prioritization ad hoc and reactive.
• Docs owners for large public sites / open-source maintainers: Large doc surfaces and many contributors lead to accumulated small errors; maintainers need automated, low-risk fixes and clear prioritization so they can focus on higher-value content.

How would they acquire their first 10, 50, and 100 customers

• First 10: Run direct, hands-on pilots via YC and founder intros. Offer a time-limited free run against the customer’s repo that delivers ready-to-merge PRs in exchange for a testimonial and a short case note.
• First 50: Publish the first pilot case studies, ship a one-click GitHub App/Marketplace install, and host community “fix-a-thon” demos at docs/DevRel meetups to drive self-serve installs with an assisted onboarding tier.
• First 100: Add integrations with popular docs platforms and support tools, partner with DevRel consultancies/channel partners, and use a light outbound motion plus a small solutions role to convert mid-market deals using pilot metrics.

What is the rough total addressable market

Top-down context:

TAM is software companies that maintain product-facing docs (developer portals, product guides, and KBs) and would pay for automated detection and remediation of stale or broken docs.

Bottom-up calculation:

Count the number of target doc surfaces (public dev docs, SDK repos, KBs) and apply a price per surface or per account by size; for example, if 10,000 relevant companies exist, 20% adopt, and ACV averages $30k, revenue potential is ~$60M/year.

Assumptions:

• Number of companies with meaningful, continuously changing documentation (e.g., ~10,000 mid-to-large targets).
• Penetration over time into that base (e.g., ~20% adoption).
• Average contract value by segment (e.g., ~$30k ACV, rising with enterprise features/SLAs).

Who are some of their notable competitors

• Postman: Keeps API docs and examples executable via Collections and Monitors, helping teams detect when examples break; overlaps on validation but not on AI-generated edits or auto-fix PRs (Docs · Monitoring).
• Stoplight / Spectral: OpenAPI design and linting with rules-based validation to catch spec/document mismatches; strong for automated checks but not focused on generative edits across large doc sets (Stoplight · Spectral).
• Vale: A prose linter used in CI to enforce style and consistency in docs; finds many low-level issues but doesn’t draft rewrites or open patch PRs automatically (Vale).
• Checkly: Synthetic API and browser monitoring to catch broken endpoints and flows referenced in docs; verifies functionality but doesn’t produce human-readable doc edits or integrate to auto-fix content (Monitors).
• ReadMe: Docs hosting and developer portal with interactive examples and versioning; reduces friction for API-first teams but is primarily a publishing platform, not an AI service for scanning and auto-fixing across repos (Product · Features).