How to build a help center and support desk with Claude Code

Rule of thumb: if support is your product’s front line and several people work it full time, buy. Routing, SLA timers, an omnichannel inbox, and a genuinely good AI agent are worth real money, and none of them is a weekend of describing. If the shape of your problem is that the same twenty questions keep arriving and you would like people to stop having to ask them, you are renting a queue to solve a library problem, and the library is the half you can own. One more finding worth weighing before you decide either way: in a Gartner survey of 5,801 customers in early 2025, 60% of agents failed to promote self-service at all, and when agents did mention it, a doubling in the number of customers likely to use it next time followed. The cheapest deflection in any support product is an agent answering with a link to the article, and no plan tier sells it to you.

* One line on the free tier matters more here than on most builds, and it is not the database size. Supabase Free comes with 500 MB of database space, 1 GB of file storage, and 5 GB of monthly egress. Articles and tickets are text and will not trouble any of that for years. What will is attachments: a support queue collects screenshots and PDFs, and 1 GB of them arrives faster than you expect. Free also pauses a project after a week without activity, which for a help center means the week you launch it and nobody has found it yet. Pro, from $25/mo, ends the pause, brings 250 GB of egress (then $0.09 per GB), and keeps a daily backup for 7 days.

What changes is which way the bill points. A rented help desk gets more expensive as your team grows and as more questions get answered. One you own costs the same either way, and the money moves to whichever AI model you choose to call and how much text you send it. The second shape suits a product whose support volume is going up, which is most products that are working.

Prices and rates from supabase.com, developex.com and claude.com, checked August 2026.

Nothing here is worth memorizing. These four just need to exist on your machine. From step 01 on, you say what you want and Claude Code runs the commands.

1. 01

   Get it running, then write the rules down

   An app booting against your own database, and a CLAUDE.md carrying the two constraints that every later step in this build depends on.

   PromptSet up the projectCopy

   Set up a new React 18 + Vite + TypeScript project with Tailwind and the Supabase JS client. Read VITE_SUPABASE_URL and the publishable key (the sb_publishable_… key, which replaces the older anon key) from .env, and add .env to .gitignore in the same step so neither value reaches GitHub. Add a typed Supabase client under src/lib, then write a short CLAUDE.md describing the stack and fixing the vocabulary for a help center and support desk (article, category, FAQ, translation, ticket, message, chat session, agent, editor) and recording two standing rules: whether an article is published is decided in the database access rules rather than in whichever query happens to be reading it, and every list of somebody else’s records (tickets, chats, attachments) is narrowed in the database rather than in a component, with a real-time subscription counting as a list.

   Put both rules in the file, not just in this message. Everything built after this point assumes them, and narrowing a ticket list inside the component is precisely the shortcut any assistant will reach for the moment an agent inbox needs one more view of the queue.

2. 02

   Model the library, then put a help center over it

   Articles, categories, FAQs, and translations, with the public reading side over them. No accounts yet, which makes this the cheap place to find out your categories do not match how people actually ask.

   PromptModel the library and build the help centerCopy

   Write the data model as Supabase migrations, with no authentication yet. Categories with a name, a slug, and a description. Articles belonging to a category, with a title, a slug, a Markdown body, a published flag, a view count, and helpful and unhelpful counts. FAQs with a question and an answer. Separate translation tables for articles, categories, and FAQs, each row carrying a locale and its own published flag, so a translation can exist as a draft while the original is live. Seed six categories and about twenty articles in a mix of lengths, including two with a Spanish translation and one left as a draft. Then build the public side: a home page, a category page, an article page that renders the Markdown with related articles under it, and a searchable FAQ. Let me click through and tell you where the category structure is wrong before anything depends on it.

   Seed a draft article and a partial translation on purpose. Those two rows are what later prove your access rules work, and inventing them now is much easier than remembering to create them at step 05.

3. 03

   Make search good enough that people stop typing

   The step that decides whether this app works, and the one most builds treat as a text input. Search the body text, not the titles, and test it with words that are not in your articles.

   PromptMake search actually workCopy

   Build search properly, using Postgres full-text search rather than a LIKE over titles. Add a generated tsvector over each article’s title and body, weight the title higher, index it, and expose a search function that takes a phrase and returns ranked results with a highlighted snippet of the matching text. Search FAQs in the same query and label which is which. Add a category filter and handle a misspelt word gracefully rather than returning nothing. Then two things I want to see: search for a phrase that appears only in the middle of one article’s body and show me it comes back, and give me a short list of queries that return nothing so I can see where the library has holes.

   Ask for the list of queries that find nothing. That list is the most useful report this application will ever produce: your customers telling you which articles do not exist yet. It costs nothing to build while search is already open in front of you.

4. 04

   Open the queue, and put the library in front of it

   Tickets with a real timeline, attachments, and the one screen worth over-building: the contact form that suggests an article while somebody is still typing their problem.

   PromptOpen the queueCopy

   Build the ticket side. Tickets carry a subject, a body, a category, a status of new, assigned, waiting on the customer, resolved, or closed, a priority, the customer they belong to, and the agent assigned to them. Messages belong to a ticket and record who wrote them and when, so the ticket page is a timeline rather than a status field. Add file attachments on both tickets and messages, uploaded to a Supabase Storage bucket, capped at 10 MB, restricted to images, PDFs, and plain documents. Then the contact form, and treat it as the most important screen here: as somebody types their subject, run the search from step 03 against it and show the three best articles above the send button, so the ticket is only created if none of them answered. Add a "my tickets" list and a ticket detail page with the timeline.

   The suggestion panel is the whole reason to have built search before the queue. Everything about it is a judgement call (how many articles, how soon they appear, whether it is a panel or a step), so look at it as a customer would before you move on.

5. 05

   Add the four roles, then prove an editor cannot read a ticket

   Your library now has drafts in it, and the queue is full of other people’s problems. Four kinds of account share this database, and each one reads a different subset of nearly every table.

   PromptAdd auth, roles, and access rulesCopy

   Add Supabase Auth with email and password: sign-up, login, logout, a persisted session, a profile row per account, and a useUser hook. Add an app_role enum of 'customer', 'agent', 'editor', and 'admin' with a user_roles table, kept out of the user's own metadata so nobody can promote themselves, and a SECURITY DEFINER has_role function. Then enable row-level security across every table with rules per role: a customer reaches only their own tickets, messages, chats, and attachments. An agent reaches the queue and the conversations in it but not the article editor. An editor reads and writes articles, categories, FAQs, and translations, including unpublished ones, and reaches no ticket at all. An admin reaches everything. Anonymous readers get published articles, categories, and FAQs and nothing else. Put that published condition in the policy, not in the query. Put explicit WITH CHECK clauses on every insert and update, and scope the storage bucket so an attachment is reachable only by the customer who sent it, the agent on that ticket, and an admin. Then prove three things by querying as a signed-in user: a customer cannot see another customer’s ticket, an editor cannot see any ticket, and an anonymous reader cannot see the draft article from step 02.

   Ask for all three proofs as signed-in queries rather than as a description of the policies. The editor role is the one to check hardest. It is the role people hand out most freely, because writing documentation feels like a low-privilege job, and it is the one most likely to have quietly been given the whole tickets table.

6. 06
   Destination

   Live chat, the admin panel, and a shift on the queue

   Real-time chat, the agent inbox, the admin panel and its numbers, the job that tidies up, and then the part most builds skip: work your own queue for an hour as each of the four roles.

   PromptAdd chat, the admin panel, and rehearseCopy

   Finish the app. Live chat first: chat sessions between a customer and an agent, messages delivered over a Supabase real-time channel rather than by polling, a waiting queue an agent picks from, a clear state for when no agent is available that turns the conversation into a ticket instead, and the same access rules on the real-time channel as on the table. Show me somebody subscribing to a conversation they are not part of and receiving nothing. Then the agent inbox with assignment and filters, the editor’s article editor with drafts, publishing, and CSV or Markdown bulk import, and the admin panel over users, roles, categories, and settings. Add analytics: article views, helpful and unhelpful counts, ticket volume by category and status, and the list of searches that returned nothing. Add a scheduled function that closes tickets nobody has touched in a period I set, protected by a shared secret rather than a sign-in. Then take me through a whole shift: search as a stranger, fail to find something, open a ticket with a screenshot, answer it as an agent, escalate a chat, write the missing article as an editor, and check as an admin that every number agrees with what just happened, fixing whatever breaks on the way.

   Do the rehearsal as all four roles in four browser profiles, not by switching your own role. Signing in as one person and changing their role is exactly the path that hides a broken policy, because your session already carries permissions the next person will not have.

Review the access rules (row-level security policies) on every table. For each one, tell me in simple terms who can view, add, edit, and delete records, confirm that people can only reach their own data while the right roles can reach more, and flag anything left open that shouldn’t be.

The one rule that matters: the database service key, any AI provider key, and the shared secret protecting your scheduled job never belong in the app or in a public repo. If one of them gets out, assume it is compromised and rotate it that day.

All of them will serve the app perfectly well, so judge them on three questions instead of one. Whether the plan permits commercial use, since Vercel’s Hobby tier does not and a help center for something you sell is commercial by any reading. Whether it can publish from a private repository, because this code sits next to an application holding your customers’ questions and whatever they attached to them. And whether you can put it on a subdomain of your own product’s domain, which matters more on this build than on any other in the catalogue, for the reason directly below.

Add a "Translate" action on an article that sends its title and body to my ai function and stores the result as a draft translation for the language I picked, never as a published one. Keep the article’s structure (headings, lists, and links stay where they are) and leave any product names, code, and UI labels I have marked as do-not-translate exactly as they were. Show it beside the original for approval before anything publishes, and mark a translation stale when the source article changes afterwards.

Add a "Draft an article from this" action on a resolved ticket. Send the conversation to my ai function and get back a draft article: a title phrased the way a customer would search for it, the steps that actually fixed the problem, and a suggested category from my existing list. Strip every specific detail first (names, email addresses, order numbers, account identifiers, and anything in an attachment) and save it as a draft for an editor to approve rather than publishing it. Where the fix depended on something specific to that customer, say so in the draft instead of writing a general instruction that will not work for anybody else.

While an agent is reading a ticket, retrieve the three most relevant published articles for it and show them beside the reply box with a button that inserts a link and a one-line summary into the draft reply. Do the retrieval against my own published articles only, in the language the customer wrote in, and pass just those articles to my ai function for the summary line. Never invent an article that does not exist, and show nothing rather than a weak match. A bad suggestion costs the agent more attention than an empty panel does.

Add an assistant on the help center that answers only from my published articles. Retrieve the relevant articles first and pass their text to my ai function, and constrain the answer to what is in that text: no general knowledge, no inference. Every answer cites the articles it came from as links the reader can check. When the retrieved text does not contain the answer, say exactly that and offer the contact form rather than attempting one. Never state a policy on refunds, delivery, warranty, cancellation, or account closure that is not written verbatim in the source it was given, and log every question it could not answer, because that log is my list of articles to write.

Add a panel on the admin dashboard that groups the last period’s tickets and chats by what they were about, using my ai function, and returns the themes with a count each, a representative example per theme, and, where the theme maps to nothing in my library, a suggested article to write. Send the subject and body text with names, email addresses, and order numbers removed, never attachments, and state the counts as figures rather than describing them vaguely. Print the period it covered beside the result so I am never reading last month as though it were this one.

Each prompt above picks the model that fits the job. As a rule of thumb, that is Haiku for high volume, Sonnet for everyday writing, and Opus for deeper reasoning. Model names move faster than this page does, so check the current list in the Claude docs (linked in the references below) before you build. Send every one of these prompts through that same ai function, so one key and one set of rules governs all of them.