Helpjuice

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me a knowledge base that replaces Helpjuice: articles my support team writes, and a search that finds the right one before somebody opens a ticket.

STACK
- Node 20+ with Fastify, server-rendered HTML
- SQLite through better-sqlite3 with FTS5 for search, WAL mode
- Caddy in front, immutable caching on assets
- One process; the public side must survive being linked from a busy inbox

THE DATA MODEL
- articles: id, slug, title, body_md, excerpt, category_id, status, author_id, published_at, updated_at, locale, version
- article_versions: id, article_id, body_md, title, saved_by, saved_at — every save, never an overwrite
- categories: id, slug, name, description, parent_id, position, icon
- searches: id, query, results_count, clicked_article_id, session_hash, created_at
- feedback: id, article_id, helpful, comment, session_hash, created_at
- users: id, email, name, role — writer, editor, admin
- redirects: id, from_path, to_path — a renamed article never 404s
- Status: draft, in review, published, archived

SEARCH, WHICH IS THE PRODUCT
- FTS5 over title, excerpt and body, with the title weighted heavily and the excerpt above the body
- Results in one query, under 20ms on ten thousand articles
- Show the matching sentence, not the first sentence
- Instant results as you type, from the server, debounced — no client-side index, no external service
- Log every search with its result count and what was clicked. The searches with no results are the backlog of articles to write, and the searches whose results nobody clicked are the articles that are answering the wrong question
- Synonyms table an editor can add to: 'invoice' and 'bill', 'cancel' and 'refund'

WRITING
- Markdown with a live preview, images pasted straight in and stored locally
- Every save is a version, and any two versions can be compared side by side and rolled back
- Review flow: a writer submits, an editor publishes. Nothing reaches the public side without that second pair of eyes
- Internal notes on an article, invisible publicly, for the reason a paragraph is worded that way
- Scheduled publishing, and scheduled expiry with a nag to the owner

STRUCTURE AND NAVIGATION
- Categories two levels deep, no more: three levels is where people stop finding things
- An article belongs to one category and can be linked from many
- Related articles chosen by hand, and suggested automatically from search co-clicks
- A table of contents from the headings, and 'in this article' on the side

THE PUBLIC SIDE
- A home page that is mostly a search box, with the most-read articles beneath it
- Article page: title, updated date, body, was-this-helpful, and the next best article
- Every page fast and readable without JavaScript. Search degrades to a form post
- A print stylesheet, because support articles get printed
- Structured data per article so a search engine can show it as a rich result

FEEDBACK THAT GOES SOMEWHERE
- Was this helpful, with an optional comment
- An unhelpful vote with a comment appears in a queue for the writers, with the search that led there
- Weekly digest to editors: most read, most unhelpful, top empty searches

MULTIPLE LANGUAGES
- One article, many locales, linked by a shared key
- A missing translation falls back to the default language and says so
- The locale switcher stays on the same article

ACCESS
- Public by default. Optional: whole base behind a login, or individual categories restricted
- Single sign-on by signed token from the main product, so a logged-in customer sees their articles without a second account

THE INTERFACE
- Two columns: categories and content. One on a phone
- Dark and light, generous line length, and type large enough to read on a support call
- No chat widget, no popups: this is a page somebody came to with a question

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, SESSION_SECRET, SSO_SECRET, SMTP_URL
- Migrations on boot, each once
- Nightly backup off the machine plus a restore script
- Health endpoint that runs a real search

WHAT MATTERS MOST
Search quality and the empty-search log are the product. Build the article model, FTS5 search and the search log first, load two hundred real articles, and tune ranking against actual queries before writing a line of the admin.

Give me the repository, migrations, .env.example, a seed with a dozen articles across three categories, and a README with deploy steps behind Caddy.