How to build a help center and support desk with Bolt

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 bolt.new, checked August 2026.

The GitHub step comes before Bolt exists for you at all. Everything after it happens inside the browser tab Bolt opens, with no install.

1. 01

   GitHub, then the import, then the rules

   Nothing opens in Bolt until a repository exists for it to open. With that imported, spend your first prompt writing rules down rather than asking for a feature.

   PromptSet up the projectCopy

   This project is a help center and support desk on React 18, Vite, TypeScript, and Tailwind. Before building any features, write a short notes file at the project root fixing the vocabulary (article, category, FAQ, translation, ticket, message, chat session, agent, editor) and recording two standing rules for the whole build: whether an article is published is enforced in the database access rules and never in the query that happens to be reading it, and every list of another person’s records, anything arriving over a real-time channel included, is narrowed in the database rather than in a component. Then set up the Supabase client to read the URL and publishable key from environment variables, confirm the environment file is gitignored, and start the app so I can see it boot.

   Both rules go into the file, not only into this prompt. Bolt reloads the whole project as context on every turn, so a rule sitting in the repository arrives again with everything else each time, and a rule you only typed into a message an hour ago does not.

2. 02

   The library and the help center, in Plan Mode

   Have the schema conversation before a line of it gets written, then let Bolt produce the entire reading side in one go. This is the inexpensive half of the build, and the half where watching a live preview genuinely tells you something.

   PromptModel the library and build the help centerCopy

   Use Plan Mode for this one. Talk me through the schema before you write 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 answer. Separate translation tables for articles, categories, and FAQs, each row carrying a locale and its own published flag, so a translation can be a draft while the original is live. Once we agree, write the migrations, seed six categories and about twenty articles of mixed length including two with a Spanish translation and one unpublished, and build the public side: 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 yet.

   Plan Mode earns its keep here specifically. The translation tables are where this schema is most often designed wrong. A locale column on the article itself looks simpler until you need the English one live and the German one still in draft, and on a tool billing by tokens, one conversation beats two rewrites.

3. 03

   One prompt for search, scoped to search alone

   Clear the context, then point this prompt at search and nothing else. It is the piece that decides whether the library is useful, and the one you least want competing with twenty article pages for attention.

   PromptMake search actually workCopy

   Clear the context from the help center work first, then work on nothing but search. Build it in Postgres rather than in JavaScript: a generated tsvector column over each article’s title and body with the title weighted higher, a GIN index on that column, and a database function taking a phrase and returning ranked results with a highlighted snippet of whatever passage matched. Include FAQs in the same query, labelled. What I do not want is articles fetched and then filtered in the app. Add a category filter, and make a misspelt word still return something sensible instead of an empty page. To finish, 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 at all.

   The live preview will not tell you this one is weak, because you wrote the twenty articles and already know what is in them. The list of phrasings that find nothing is the check that does not depend on what you happen to remember.

4. 04

   The queue, and the screen that stops it filling up

   Tickets, attachments, and the contact form that runs a search before it creates work. Everything here is visible in the preview, which makes it the fastest step of the six.

   PromptOpen the queueCopy

   Build the ticket side. A ticket knows its subject, body, category, whether it is new, assigned, waiting on the customer, resolved, or closed, its priority, the customer it belongs to, and the agent assigned to it. A message knows its ticket, its author, and when it was written, so a ticket page is a timeline and not a status field. Add attachments on tickets and messages, uploaded to Supabase Storage, capped at 10 MB, limited to images, PDFs, and plain documents. Then finish the contact form, which is the most important screen in this step: while somebody types their subject, run the search from step 03 against it 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 with the timeline.

   Watch the suggestion panel in the preview while you type a real question badly, with a typo and the wrong word for your own feature. That is how your customers will type it, and it is the only test of this screen that means anything.

5. 05

   Four roles and their rules, on a cleared context

   One contained change that nonetheless reaches every table in the schema. Begin it clean: your token bill is one reason, and the other is that a single coherent commit is far easier to read back in six months.

   PromptAdd auth, roles, and access rulesCopy

   Clear the context, then do authentication and access rules as one piece of work. Email-and-password sign-up, login, logout, a persisted session, and a profile row per account. Four roles (customer, agent, editor, admin) in their own table rather than on the account record, since anything stored there is editable by its owner, with a security definer function for checking a role. Then row-level security on every table, per role: 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 visitor who is not signed in gets published articles, categories, and FAQs only, with that published condition in the policy rather than in a query. Explicit with-check clauses on inserts and updates, and the storage bucket scoped so an attachment is reachable only by its customer, the agent on that ticket, and an admin. Then sign in as each role in the preview and show me that a customer cannot see another customer’s ticket, an editor cannot see any ticket, and a signed-out visitor cannot see the draft article.

   Read the commit Bolt makes for this one on GitHub afterwards. Four roles over twenty-odd tables produces a great many policies, and a summary of what happened is exactly the wrong format for checking whether the one covering attachments got written.

6. 06
   Destination

   Chat, the admin panel, and publishing before you link to it

   Real-time chat, the back office, a full shift on your own queue, and a deploy that happens before you put the help center link in your product.

   PromptAdd chat, the admin panel, and rehearseCopy

   Finish the app. Live chat first: chat sessions between a customer and an agent, messages over Supabase real-time rather than polling, a waiting queue an agent claims from, a clear state for when nobody is available that turns the conversation into a ticket, 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 searches that returned nothing. Add a scheduled function closing 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, 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 then publish, and tell me which environment variables the published build needs that the preview never asked for.

   Put that final question in writing. Configuration for a published build comes from the host, not from the file sitting on your own machine, and a help center that is empty on launch day is nearly always that and hardly ever the code.

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.

Pick a lighter model for the high-volume prompts above and save a stronger one for wherever the reasoning actually matters. That is the same token-budget logic as the rest of this page, applied to the app’s own AI calls instead of the build itself. When Bolt flags a missing secret, add the key through its secrets settings instead of pasting it into the chat, and keep every AI feature behind one server-side function so there’s only one key to manage.