How to build a help center and support desk with Replit

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 replit.com, checked August 2026.

The first two are all you need to start. Everything here stays inside the one browser tab, the app included once you publish it, and the GitHub copy is the one deliberate exception.

1. 01

   The app, the database, and the ground rules, in one message

   Postgres here is part of the workspace rather than an account you open elsewhere, so asking for it belongs in the very first message, alongside the two constraints that everything after this leans on.

   PromptSet up the project and the databaseCopy

   Set up a React 18 + Vite + TypeScript app with Tailwind and a server, and add a Postgres database to this Repl, the one Replit provisions, not anything outside. Write a short notes file at the project root recording three things. This is a help center and support desk. The words throughout are article, category, FAQ, translation, ticket, message, chat session, agent, and editor. And two standing rules: whether an article is published is enforced in the database access rules rather than in whichever query is reading it, and every list of another person’s records is narrowed in the database rather than on a page, with whatever transport eventually carries chat messages counting as a list. Keep the database connection details in Replit's Secrets rather than in the code.

   Get both rules into the notes file, not just into this message. Narrowing results on the page is what any assistant reaches for when an agent inbox needs one more view of the queue, and on this app that particular shortcut is how one customer ends up reading another customer’s problem.

2. 02

   The library and the help center, checked at a checkpoint

   Schema and public reading side in one go. Nothing writes anything yet, which makes this the inexpensive moment to discover that your categories do not match the way people actually ask.

   PromptModel the library and build the help centerCopy

   Design the schema and the server routes over it. Categories with a name, slug, and description. Articles in a category with a title, slug, Markdown body, published flag, view count, and helpful and unhelpful counts. FAQs with a question and an answer. And separate translation tables for articles, categories, and FAQs, each row carrying a locale and its own published flag, so a translation can sit as a draft while the original is live. Seed six categories and about twenty articles of mixed length, two with a Spanish translation and one left unpublished. Then the public side over it: a home page, a category page, an article page rendering the Markdown with related articles under it, and a searchable FAQ. No accounts and no tickets in this message, and no route may return an unpublished article.

   Look at your own category list in the preview before going further, and take the checkpoint. Categories are the one structural decision customers navigate directly, and the version that read well while you typed it often does not survive seeing it as a menu.

3. 03

   Search in Postgres, written by the Agent

   The step that decides whether the library earns its keep. Ask for it in the database explicitly, and judge it on searches you did not write the articles for.

   PromptMake search actually workCopy

   Build search in Postgres rather than in the application. Add a generated tsvector column over each article’s title and body with the title weighted higher, a GIN index on it, and a database function that takes a phrase and returns ranked results with a highlighted snippet of the passage that matched. Include FAQs in the same query, labelled. Expose it through one server route the search box calls, and do not fetch articles and filter them in the route. Add a category filter, and make a misspelling still return something sensible. Then, in the preview, show me a phrase that appears only in the middle of one article’s body coming back with that article, and print a list of plausible customer phrasings that currently return nothing.

   Checkpoints pay for themselves at this step. Search touches the schema, and rolling a checkpoint back offers to bring the database with it, which is exactly what you want while every row is a seed you invented, and exactly what deserves a second thought once real tickets exist.

4. 04

   The queue, with attachments served by your own server

   Tickets, their timeline, and the contact form that searches before it creates work. Attachments need a decision here that they do not need on the other tools.

   PromptOpen the queueCopy

   Build the ticket side. A ticket records its subject, body, category, a state of new, assigned, waiting on the customer, resolved, or closed, its priority, the customer it belongs to, and the agent assigned to it. A message records its ticket, its author, and when it was written, so a ticket page reads as a timeline rather than a status. Then attachments: I want files uploaded through my own server, stored in object storage, capped at 10 MB, limited to images, PDFs, and plain documents, and served back only through a route that checks who is asking, never from a URL that works for anybody holding it. Then finish the contact form, the most important screen in this step: as somebody types their subject, call the step 03 search route and put the three best articles above the send button, so a ticket only gets created when none of them answered. Add a "my tickets" list and a ticket detail page.

   Be firm about attachments going through a route rather than a public URL. A support attachment is usually a screenshot of an order confirmation, complete with a name and an address, and a link that works for anybody who has it is a link that will eventually be somewhere you did not put it.

5. 05

   Sign-in, four roles, and policies that read what your server declares

   No account id reaches this database on its own, so both ends of the chain are the Agent’s to build: the sessions your server hands out, and the policies that read whichever identity your server has declared.

   PromptAdd sign-in, roles, and access rulesCopy

   Build sign-up, login, logout, and a server-side session on email and password, with one profile row per account. Add a roles table giving each account customer, agent, editor, or admin, in its own table, never on the account record, since anything there is editable by that user. Then turn on row-level security across every table: have the server declare the current account and its role as session-local settings at the start of every request, and write the policies to read them. A customer reaches only their own tickets, messages, chats, and attachments. An agent reaches the queue and its conversations 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. A request with no account declared gets published articles, categories, and FAQs only, with that published condition in the policy rather than in a route. Then show me how to prove, as a signed-in customer, that another customer’s ticket comes back empty, that an editor sees no tickets at all, and that a signed-out request cannot read the draft article.

   With no hosted identity service handing Postgres an account id, your own server is the only thing in the system that knows who is asking. Get the declaration working before writing a single policy: policies with nothing to read do not fail loudly, they pass everything, and what they would be passing here is every customer’s ticket history.

6. 06
   Destination

   Chat you have to transport yourself, then publishing

   The one step where this tool asks for more than the others: this workspace has no real-time service, so the chat transport is part of the build. Then the back office, a full shift, and Publishing.

   PromptAdd chat, the admin panel, and publishCopy

   Three things left. First, live chat, and note that this database has no real-time service attached, so tell me which transport you are using, a websocket on my own server or short polling, and why. Chat sessions between a customer and an agent, a waiting queue an agent claims from, an explicit state for when nobody is available that turns the conversation into a ticket, and (the part that matters) every message the transport delivers must pass the same checks as a query on the table, with the session-local account and role declared before anything is read. Show me somebody connecting to a conversation they are not part of and receiving nothing. Second, the back office: an agent inbox with assignment and filters, the editor’s article editor with drafts, publishing, and CSV or Markdown bulk import, the admin panel over users, roles, categories, and settings, and analytics for article views, helpful counts, ticket volume by category and status, and the searches that returned nothing. Third, a job that closes tickets nobody has touched in a period I set, authenticated by a secret from Replit's Secrets rather than a session. Then help me work a whole shift: search as a stranger, fail, file a ticket with a screenshot, answer it as an agent, take a chat, write the missing article as an editor, check the admin numbers, and when that holds, take me through Publishing: which deployment type suits the app given it holds a websocket open, which suits the ticket-closing job, and who the app ought to be visible to on day one.

   The transport question is the one to insist on an answer to. A websocket and short polling behave very differently once the app is published across more than one instance, and this is the only build in the set where the tool that hosts you does not hand you a real-time service to sidestep the question with.

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 connection, any AI provider key, and the shared secret protecting your scheduled job never go into the app or a public repo. If one gets out, treat it as compromised and rotate it the same day.

All of these are Replit rather than a third party, so the choice is shape rather than vendor, and this build wants two of them: one to serve the app, and Scheduled for the ticket sweep. Review who the app is visible to before the first release, since Publishing is what sets it.

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.

A cheap model is plenty for most of the prompts above. Save Pro’s stronger models for the one or two spots where the extra reasoning actually pays for itself. Add any provider key through Replit’s own Secrets tool rather than hard-coding it, and keep every AI feature behind one server-side function so a single key covers the whole app.