How to build a help center and support desk with v0

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, v0.app, v0.app and vercel.com, checked August 2026.

The database step is the one worth not skipping once your screens need real data. Everything else here takes a couple of minutes, and after that you’re just describing what you want.

1. 01

   Sketch the reading screens first, because that is what v0 leads with

   The whole public side with placeholder articles, in one chat. The point is to look at how somebody moves from a question to an answer before anything is stored anywhere.

   PromptSketch the help centerCopy

   Build the public screens for a help center in Next.js, using placeholder content for now. A home page led by a search box with popular categories under it. A category page listing its articles. An article page rendering Markdown with a table of contents, related articles, and a was-this-helpful control at the foot. A searchable FAQ page. A contact form with a panel above the send button where suggested articles will appear. Include one long article and one very short one so I can see both. Keep it responsive. A lot of my readers will arrive on a phone from a link in a support reply.

   Use Design mode for the visual corrections rather than describing them. On a help center, type size, line length, and how an article page reads on a phone are most of the product, and they are exactly what Design mode is for.

2. 02

   Connect the database and let the screens read real articles

   Where the hand-off happens. Add the integration from the project menu, then ask for a schema and the routes that will retire every placeholder you just looked at.

   PromptModel the library and connect the databaseCopy

   A Supabase integration is now connected to this project. Design the schema and the routes reading it, then swap the placeholder content out of the screens you already built. 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. Seed six categories and about twenty articles, two with a Spanish translation and one unpublished. Write server-side routes for the home page, a category, and a single article, and wire the existing pages to them. Nothing writes yet, and no route may return an unpublished article.

   Get this done before another screen exists. From here on everything reads or writes a real row, and any page designed against an invented shape has to be rebuilt the moment the real shape turns out to differ from it.

3. 03

   Ask for search in the database, not in the route

   The step that decides whether the library is worth having, and the one where a tool that leads with interfaces will happily give you something that looks like search and filters an array.

   PromptMake search actually workCopy

   Start a new chat for search. Build it in Postgres, not in JavaScript: 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-side route the search box calls. What I am asking you not to do is fetch articles and filter them in the route or the component. The ranking and the matching belong in the database. Add a category filter and handle a misspelling without returning an empty list. Then show me a phrase that appears only in the middle of one article’s body coming back with that article, and a list of plausible customer phrasings that currently return nothing.

   Say "in the database, not in the route" explicitly and then check the diff for it. Filtering a fetched array is the natural thing to write when the interface came first, and it is invisibly wrong: it works perfectly on twenty seeded articles and quietly stops scaling at four hundred.

4. 04

   The queue as its own chat: tickets, attachments, and the suggestion panel

   The first thing here that writes anything. Keep it in a chat of its own: restoring a version is likely at some point, and you do not want the help center travelling backwards along with it.

   PromptOpen the queueCopy

   New chat for the ticket side. Two tables: a ticket, which records 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. Then a message, which belongs to a ticket and records who wrote it and when, so a ticket renders as a timeline rather than a status. Add attachments on tickets and messages, uploaded to storage, capped at 10 MB, limited to images, PDFs, and plain documents, and served only through a route that checks who is asking rather than from a public URL. Then finish the contact form you sketched in step 01: as the subject is typed, call the search route from step 03 and fill the panel above the send button with the three best articles, so a ticket only gets created when none of them answered. Add the "my tickets" list and a ticket detail page.

   The attachment rule is the one to be firm about. A storage URL that works for anybody holding it is the default in most integrations, and a support attachment is a screenshot somebody sent you privately, very often of an order confirmation with their address on it.

5. 05

   Roles and access rules, in a separate chat and its own pull request

   Four kinds of account over the same tables, each reading a different subset. Its own chat again, and its own reviewable diff.

   PromptAdd auth, roles, and access rulesCopy

   New chat, for authentication and access rules. Add email-and-password sign-up, login, logout, a persisted session, and a profile row per account. Add four roles (customer, agent, editor, admin) in a separate table rather than on the account record, since anything stored there is editable by its owner, with a security definer function to check 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. An anonymous reader gets published articles, categories, and FAQs only, with the published condition in the policy rather than in a route. 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 prove three things by querying as a signed-in user: one customer cannot read another’s ticket, an editor cannot read any ticket, and an anonymous reader cannot read the draft article.

   Give this its own pull request instead of stacking it on the ticket work. Of every change in this build, the access rules are the one you will most want to read back as a single self-contained diff six months from now.

6. 06
   Destination

   Chat, the admin panel, then merge and deploy

   Real-time chat, the back office, a full shift on your own queue, and only then the merge that publishes it.

   PromptAdd chat, the admin panel, and rehearseCopy

   Last chat. Live chat first: chat sessions between a customer and an agent with messages arriving in real time rather than by polling, a waiting queue an agent claims from, an explicit state for when no agent is available that turns the conversation into a ticket, and the same access rules on the real-time transport as on the table. Show me somebody subscribing to a conversation they are not part of and receiving nothing. Then the rest: an agent inbox with assignment and filters, the editor’s article editor with drafts, publishing, and CSV and Markdown bulk import, and the admin pages for users, roles, categories, and settings. Analytics next: article views, helpful and unhelpful counts, ticket volume by category and status, and the searches that came back empty. Then a scheduled job that closes tickets nobody has touched in a period I set, authenticated by a shared secret rather than a session, and tell me where that schedule has to live given this app deploys to Vercel. Finally, walk a whole shift with me: 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, and confirm as an admin that the numbers agree.

   Ask where the schedule lives rather than assuming. A scheduled job is the one piece of this build that is not a request from a browser, and it is the piece most likely to be quietly left out and noticed months later, when your oldest open ticket turns out to be from launch week.

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.

v0 doesn’t ship its own model for these prompts, so you bring an API key for whichever provider you want, and v0 writes the route that calls it. Start with a cheap model while you’re still iterating on the prompt itself, then swap in a stronger one for the version that ships, and keep every AI feature behind that one route so there’s only one key to rotate.