Meet Marcus
Marcus runs a developer-tools SaaS for database migrations. The product helps backend teams move data between Postgres versions without writing migration scripts by hand. Marcus is the founding engineer; his team is two more people, one part-time designer and one part-time DevRel. They are bootstrapped, profitable in a thin way, and their entire top-of-funnel is the docs site he built himself with Docusaurus.
The docs site gets about 800 visitors per week from Google search. Trial conversion sits around 8 percent of visitors who reach the homepage. The number Marcus does not have is how many of the 800 docs visitors bounced because they could not find what they came for. He suspects most of them did, because Search Console says 60 percent of docs sessions are single-page-no-click, and his Plausible dashboard puts average time on page for a Google-landed visitor at 38 seconds.
Marcus knows what those visitors are asking. He sees it in his Twitter mentions, his Discord, his sales calls. The questions are concrete: "does it work with Postgres 17?" "is the CDC mode compatible with logical replication slots?" "what happens if a migration fails halfway through?" The visitor types one into Google, lands on the page Google thinks is most relevant, scans for 30 seconds, does not see their exact phrase, and closes the tab.
The information was usually there. Three paragraphs into a different page, or an example in the recipes section, or the third sentence of the FAQ. The visitor did not find it because Marcus organized the docs the way a builder organizes information, not the way a stranger searches for it. This is the gap a chatbot trained on his docs closes.
Why "the search box is fine" is the wrong answer
Marcus already has a docs search box. Docusaurus ships with Algolia DocSearch, and DocSearch is genuinely good at what it does. So why is search not enough?
Three reasons that compound. First, search returns documents, not answers. A visitor who types "Postgres 17 support" sees a ranked list of doc pages and still has to click in, scan for their phrase, and decide if the page answers them. Every step is a chance to bounce. A chatbot returns a sentence with a citation instead.
Second, search requires keyword overlap. If the visitor types "does it work with PG 17?" and your docs say "PostgreSQL 17 is supported," DocSearch's vector embeddings catch most of the gap, but not all of it. Hybrid retrieval (BM25 plus semantic) catches more, and the conversational layer rewrites the user's question into something retrieval understands.
Third, search has no memory. The visitor who asks "how do I set up CDC mode" and then "what about with a replica" is on their own to combine those queries. A chatbot carries context forward.
None of this makes DocSearch bad. Marcus should keep his search box. The chatbot is the second floor, not a replacement.
The before-state, in numbers Marcus can name
Before ChatRaj, the funnel for Marcus's docs looked like this. About 800 visitors per week reached a docs page. About 60 percent bounced single-page. Of the 320 who clicked through, perhaps a third reached the docs homepage or pricing page. Of those who reached pricing, about 8 percent started a trial. The math is harsh: 800 in, roughly 8 trials out, roughly 1 percent end-to-end conversion.
The question Marcus could not answer was the most important one: of the 480 visitors who bounced single-page, how many had a specific question that the docs already answered somewhere? Plausible could tell him people left; it could not tell him what they were looking for.
A content-grounded chatbot changes the visibility shape. Every question typed into the chat is captured: the question text, the matched doc citations, whether the bot answered confidently, the visitor's rating, and whether the conversation ended in a captured email or a trial signup. Marcus now has telemetry on the part of the funnel that was a black box.
The questions visitors ask docs that the docs do not answer well
After a month of running ChatRaj, Marcus's Unanswered tab has a recognizable shape. Questions cluster into five categories.
One, version compatibility: "Does it work with Postgres 17?" "Aurora 15?" "Mongo 7?" Visitors need a yes or no before evaluating further. Marcus has a Compatibility page, but it is two clicks deep from feature pages, and Google-landed visitors never reach it.
Two, integration: "Does it work with GitHub Actions?" "Can I trigger it from a Vercel cron?" "Terraform?" These are questions where a yes converts an evaluator and a no sends them to a competitor.
Three, failure-mode: "What happens if the migration fails halfway?" "Can I roll back?" "Does it leave partial state?" Risk-aware evaluators ask these before running anything against production. Marcus's Reliability section is written in terms of internal architecture, not the failure modes a buyer is afraid of.
Four, pricing-shape: "Is the OSS version production-ready?" "What is the difference between OSS and Cloud?" "Do I need the paid tier to use CDC?" These belong on the pricing page but end up in the docs because the visitor is researching, not shopping.
Five, long-tail "how do I": "How do I migrate from Heroku Postgres to Neon?" "How do I dry-run a migration?" "How do I rotate credentials mid-migration?" The docs have answers to most of these, scattered.
The shape of this list is the most useful thing the chatbot gives Marcus. Before ChatRaj, he was guessing what to write about next. Now the Unanswered tab is his content roadmap, ranked by how many distinct visitors asked the same kind of question.
Deflection versus evaluator conversion: not all chats are equal
Marcus is not a support team. He is a founder. His chatbot is not deflecting customer-service tickets the way an ecommerce chatbot deflects "where is my order." It is doing something different: catching evaluators who would have bounced and either answering them well enough to keep them evaluating, or capturing their email so Marcus can follow up.
The two outcomes have different value. A deflected support ticket saves a few minutes. A converted evaluator is worth, for a developer-tools SaaS at Marcus's price point, on the order of a paying customer's lifetime value. The split on a docs surface is heavily weighted toward the second.
ChatRaj's dashboard surfaces this split. Conversations where the bot confidently answers and the visitor moves to pricing or signup are flagged evaluator-converting. Conversations ending in a captured email with no signup are lead-captured. Conversations with no email, no signup, and low confidence are unanswered. Marcus can reason about each bucket separately. For him, after one month, the rough split is 30 percent confidently answered, 15 percent lead captured, 20 percent unanswered, and the rest miscellaneous.
The build versus buy decision for SaaS founders
Marcus is a backend engineer who could absolutely build a RAG chatbot from scratch. He has used the OpenAI API for two years and built a vector store with pgvector. The honest question is whether building wins.
The pure dev cost of v0 is small: a weekend to wire up embeddings against his docs, another weekend to build a chat UI that calls his retrieval endpoint, a week to host it, set up auth, and add basic rate limits.
What is not cheap is everything after v0. Citations that link to the right anchor, not the right page. Hybrid retrieval, because pure vector search drops exact-keyword queries like "Postgres 17" reliably. A semantic cache so repeat questions do not burn LLM credits. Confidence scoring so the bot knows when to abstain instead of hallucinating. Conversation history. Lead capture. CSAT. Multi-language. GDPR-compliant logging. An Unanswered tab. Webhooks. Re-indexing when docs change. None of those are hard individually; all of them together are six months of part-time work Marcus could spend shipping product features instead.
The build-versus-buy math for a SaaS founder is almost never "can I build this." It is "is the feature coverage gap worth the opportunity cost of not shipping the next product feature." For Marcus, with a three-person team and a thin runway, the answer is buy. The Build vs buy comparison below makes that explicit.
The exception is real. If you have ML expertise on the team, or your bot needs a corner-case capability (function-calling against your own API, retrieval over a non-text source like a video library, a custom ranking model trained on your domain), building can be the right call. ChatRaj is built for the 90 percent of SaaS docs use cases that look like Marcus's. We are honest about the 10 percent where it is not.
Integration with your existing docs stack
ChatRaj does not care which docs framework you use. The integration point is a single script tag in the global layout, and the knowledge base is your sitemap URL.
For Docusaurus, the script tag goes in docusaurus.config.js under scripts. For VitePress, in .vitepress/config.mts under head. For MkDocs, in extra_javascript in mkdocs.yml or overrides/main.html. For Mintlify, in mint.json under the scripts block. For Nextra, in theme.config.tsx under the head block. For Notion-published docs through Super.so or Potion.so, in the host tool's Global Code section (see /for/notion). For raw HTML docs, in your footer template (see /for/html).
The snippet is identical in every case: a single script tag with your bot ID. The bot trains on the public docs by reading sitemap.xml, so the only setup decision is which sitemap to point ChatRaj at.
Day 1 versus Day 30
Day 1 looks like a quiet success. The bot is on the site, visitors are using it, conversations show up in the dashboard, and Marcus can read transcripts. There is no immediate revenue impact; it is a tool he just installed.
Day 30 looks different. The Unanswered tab has 60 to 100 distinct questions clustered into the five categories above. Marcus opens his Docusaurus repo, picks the top three clusters, and writes three new doc pages over a weekend. The next month, those clusters disappear from Unanswered and the bot's confidence rate on related questions jumps. Marcus has used his chatbot as a directed content prioritization system: he is writing the docs his visitors actually want, not the docs he assumed they wanted.
This is the compounding loop. Every week the Unanswered tab becomes the next sprint's editorial backlog. The bot gets better because the docs get better. The docs get better because the bot tells you, with evidence, what is missing.
When this does NOT work
ChatRaj on docs is not magic. Three honest scenarios where the win is smaller.
If your docs are mostly API reference (OpenAPI-generated), a chatbot helps less than you would expect. Reference is already well-structured for search; the long-tail questions tend to be "how do I combine these endpoints," which need examples your reference does not contain.
If your traffic is dominated by repeat visitors who already know your docs, the chatbot is more convenience than conversion lever. Those visitors were not going to bounce-and-evaluate-a-competitor.
If your product is mid-market or enterprise and evaluators do their research through your sales team rather than your docs, the docs chatbot helps marginally; the real lever is sales enablement.
For Marcus, none of these apply. His docs are prose, his traffic is new-from-Google, and his product is sold self-serve. He is exactly the persona this page describes.
Next step
If your docs run on Docusaurus, VitePress, MkDocs, Mintlify, Nextra, or a Notion-published handbook, the deploy is one script tag and a sitemap URL. The seven steps below walk through it. The free tier is enough to evaluate whether the Unanswered tab tells you something useful. If it does, the Pro tier at $29 per month covers 10,000 messages with no overage, more than most indie SaaS docs sites see in a month.