How to build a help center and support desk with Lovable

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 docs.lovable.dev, checked August 2026.

Only the first three are needed to start, and none of it touches your computer. From here, you describe what you want and Lovable builds it in the browser.

1. 01

   The database connection comes before the first screen

   Any screen built over data that does not exist yet is a screen you rebuild once it does. Get the database attached first, and state the two rules this build rests on while the conversation is still short enough for them to stick.

   PromptSet up the projectCopy

   Connect my Supabase project before building any screens at all. Then set up a help center and support desk, and hold two rules for the rest of this project: whether an article is published is decided by the database access rules and never by whichever query is reading it, and every list of another person’s records (tickets, chats, attachments, and anything arriving over a real-time channel) is narrowed in the database rather than in a screen. Use these words consistently throughout: article, category, FAQ, translation, ticket, message, chat session, agent, editor. Confirm the connection is live, then tell me which of those two rules changes how you will design the articles table, before you design it.

   That closing question earns its extra exchange. It is the cheapest available way to learn, right now, whether the model Lovable has in mind treats an unpublished article as a row anybody may read and a screen politely hides, or as a row the database refuses to hand over at all.

2. 02

   Describe the library, and watch the help center appear

   The part Lovable is fastest at, and the part where looking at it beats specifying it. Get your category structure in front of your own eyes before a single ticket exists.

   PromptModel the library and build the help centerCopy

   Design the tables and build the public reading side over them. 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. 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. Add six categories and about twenty articles of mixed length as sample data, two with a Spanish translation and one left unpublished. Then 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. No sign-in and no tickets in this message.

   Click your own category list in the preview before moving on. Categories are the one structural decision customers see directly, and the version that made sense while you were typing it often does not survive looking at it as a menu.

3. 03

   Ask for real search, in those words

   A preview will not show you that search is weak, because you know what your twenty articles say. Ask for full-text search explicitly and test it with words you did not write.

   PromptMake search actually workCopy

   Build search properly, and treat this as one of the two most important messages in the project. Use Postgres full-text search rather than matching on titles: a generated search column over each article’s title and body with the title weighted higher, an index on it, and a database function that takes a phrase and returns ranked results with a highlighted snippet of the passage that matched. Search FAQs in the same query and label which results are which. Add a category filter and make a misspelt word still return something sensible. Then show me two things by running them: a phrase that only appears in the middle of one article’s body finds that article, and a list of plausible customer phrasings that currently find nothing.

   Bookmark where you are before sending this one. Of everything in this build, search is the likeliest to take two or three goes, and returning to a version you know worked is far easier than untangling a schema left half-changed.

4. 04

   The queue, and the screen that answers before it fills

   Tickets with a real timeline, attachments, and the one screen that decides how much of your queue never arrives at all: a contact form offering answers while somebody is still typing the question.

   PromptOpen the queueCopy

   Build the ticket side. Tickets carry a subject, body, 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 reads as a timeline rather than a status field. Add file attachments on tickets and messages, uploaded to Supabase Storage, capped at 10 MB, limited to images, PDFs, and plain documents. Then the contact form, and treat it as the most important screen here: while somebody types their subject, run the step 03 search against it and show the three best articles above the send button, so a ticket is only created if none of them answered. Add a "my tickets" list and a ticket detail page with the timeline.

   Use Select elements on the suggestion panel rather than describing it. How prominent those three articles are, and how soon they appear, is the whole design of this screen, and it is far quicker to point at than to word.

5. 05

   Four roles, and the rules that read them

   Customers, the agents answering them, the editors writing the library, and the admins running the whole thing. A rule per role on every table is what this comes to, and it is why the step takes longer than its description suggests.

   PromptAdd auth, roles, and access rulesCopy

   Add email-and-password sign-up, login, logout, a persisted session, and a profile row per account. Add four roles (customer, agent, editor, and admin) in their own table rather than on the account record, since anything stored there is editable by the person it belongs to, with a security definer function to check a role. Then turn on 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 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. Add explicit with-check clauses on inserts and updates, and scope the storage bucket so an attachment is reachable only by its customer, the agent on that ticket, and an admin. Then, in the preview, sign in as each role in turn 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.

   Ask to see it as three signed-in previews rather than as a summary of the policies. The editor role is the one to test hardest: writing documentation feels like a low-privilege job, which is exactly why an editor often quietly ends up with the whole tickets table.

6. 06
   Destination

   Chat, the admin panel, and one last bookmark

   The real-time chat, the inbox, the admin panel with its numbers, and the tidy-up job. Then a full shift worked on your own queue, and a bookmark taken the moment that shift passes, before a domain points anywhere near it.

   PromptAdd chat, the admin panel, and rehearseCopy

   Finish the app. Live chat first: chat sessions between a customer and an agent, messages delivered over Supabase real-time rather than polling, a waiting queue an agent picks 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 getting nothing back. 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 that closes tickets nobody has touched in a period I choose, protected by a shared secret rather than a sign-in. Then walk me through a whole shift in the preview: search as a stranger, fail to find something, open a ticket with a screenshot, answer it as an agent, take a chat, write the missing article as an editor, and check as an admin that every number agrees with what just happened.

   The version that gets through that shift is the one to bookmark, before a domain or any further change touches it. It is your last recorded point where all four roles and both halves of the application demonstrably worked together, which makes it the version you will eventually want to return to.

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.

One button, and the app you have been previewing is live.

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.

You bring no key and pick no provider: Lovable manages an API key per project, and if you do not name a model it chooses one from what you describe. Match the model to the job: fast and cheap for anything that runs on every record, stronger only where the reasoning matters. Send every feature above through that one integration.