Every SaaS founder eventually hits the same wall: you are spending more time writing the same email than building the product. A customer asks how to reset their password. Another asks where the billing page is. A third wants to know if you have an API.
You answer. The next week, the same three questions arrive.
A help center breaks this cycle. Not because it is better UX -- though it is -- but because it compounds. Every article you write answers that question forever, for every customer, at any hour.
An AI chatbot (like the one you can add with Claude) is powerful once it has content to read. A help center is that content -- it is what the chatbot indexes, and it is what Google ranks.
A searchable help center does three things a chatbot alone cannot:
Build the docs first. Add the chatbot later when you have something for it to reference.
A help center is a searchable collection of articles grouped by function. The same MDX setup you might already use for your blog works here with two additions: a category structure and a search endpoint.
If you are using this Next.js SaaS boilerplate, the MDX pipeline is already wired. The difference from a blog is organization -- group articles by job (Getting Started, Billing, Account) rather than by date.
content/
help/
getting-started/
first-steps.mdx
what-is-this.mdx
billing/
how-billing-works.mdx
cancel-subscription.mdx
account/
reset-password.mdx
change-email.mdx
Each article exports its metadata:
export const meta = {
title: 'How to reset your password',
description: 'Step-by-step guide for resetting your account password.',
category: 'account',
order: 1,
}The help center home page lists categories and their top articles. Because it is a Next.js server component, it discovers files at build time without a database query:
// lib/help.ts -- discovers MDX files from content/help/**, groups by category
export async function getHelpArticles() { ... }Render the page as a two-column layout: category cards on the left, and a "popular articles" list on the right. Populate the popular list with the three or four articles you paste into support replies most often.
Customers searching "how do I cancel" will not find your cancel-subscription.mdx if the query does not match the filename or first sentence. Full-text search fixes this.
Store article content in a help_articles table in your Neon DB and use PostgreSQL's built-in full-text search. When a customer types a question, the endpoint returns the most relevant articles in under 100ms.
// helpRepo.ts
return db
.select()
.from(helpArticleTable)
.where(
sql`to_tsvector('english', ${helpArticleTable.content}) @@ plainto_tsquery('english', ${query})`
)
.limit(5)This is the same Drizzle ORM tsvector pattern from the full-text search post -- adapted from product data to documentation content.
The most valuable output of a help center is not the articles themselves. It is the search logs.
Every zero-result search is a customer question you have not answered yet. Log every search in a help_searches table -- query, result count, user ID (nullable), and timestamp. Review it every week. Zero-result queries become your content backlog.
This is the same event tracking pattern applied to documentation instead of product behavior. The queries that return nothing are more useful than the ones that succeed.
Support replies slow down. Customers at 2am in a different time zone find their answer without waiting for you. Help center pages rank in Google and bring in users who searched for a problem your product solves -- before they even know your product exists.
The build time for a basic help center is a few hours. The compounding starts the same day.
If you want to skip the setup and ship your help center this afternoon, the Next.js SaaS boilerplate already includes the database, MDX pipeline, full-text search, and auth so you can focus on writing the articles instead of wiring the infrastructure.