Chatwoot

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 the support inbox I actually need instead of a hosted Chatwoot: live chat and email in one place, with canned replies and a help centre.

Read this first: the product you are replacing is open source, and self-hosting it is a real answer. What you pay for is the hosted instance and the social channel integrations — WhatsApp and Instagram each need an approved application, and that is the part you cannot build around. If chat and email are enough, build this.

STACK
- Node 20+ with Fastify, server-rendered HTML with a little vanilla JS
- SQLite through better-sqlite3, WAL mode
- A chat widget under 20KB gzipped, from my own domain
- Caddy in front

THE DATA MODEL
- contacts: id, email, name, phone, external_id, traits_json, first_seen_at, last_seen_at
- conversations: id, contact_id, channel, subject, status, assignee_id, team_id, priority, first_response_at, resolved_at, created_at
- messages: id, conversation_id, direction, author_kind, author_id, body_md, body_html, is_private, delivered_at, read_at, created_at
- attachments: id, message_id, path, sha256, mime, bytes
- email_threads: conversation_id, message_id_header, references_json — how a reply finds its conversation
- canned_replies: id, shortcut, title, body_md, team_id
- labels, teams, agents, and a mapping between them
- sla_targets: id, priority, first_response_minutes, resolution_minutes
- events: id, conversation_id, kind, actor, meta_json, at — append-only, and the whole history of a conversation

EMAIL, WHICH IS HARDER THAN CHAT
- Inbound by a provider webhook or by IMAP, parsed properly: MIME, HTML and text alternatives, inline images, attachments, and the quoted history stripped for display but kept in full
- Threading by Message-ID, In-Reply-To and References, with a subject-plus-participant fallback. Never by subject alone — 'Re: your order' from two customers must not become one conversation
- Outbound sets the headers that keep the thread intact, and comes from an address on a domain with SPF, DKIM and DMARC configured. The README lists the records
- Automatic replies and bounces detected and not turned into a customer conversation, which is how a support inbox starts talking to itself
- A per-recipient send cap, so a loop cannot mail somebody four hundred times

THE CHAT WIDGET
- One script, one init call, optionally with a signed identity token from my backend
- Shadow DOM, my accent, dark and light, keyboard navigable, focus trapped while open, Escape closes
- Messages delivered by polling a small endpoint with a backoff, faster while the conversation is active and slower when it is idle. Sockets are the obvious answer and the wrong first one: polling is far simpler and enough for any volume a small team handles. Say where that stops being true
- Offline: when nobody is available, the widget says so honestly and takes an email address instead of pretending
- The full conversation history for an identified visitor, so they do not start again on every page
- Typing indicators and read receipts only if they are real. A fake typing indicator is a small lie that people notice

THE INBOX
- One list with filters: unassigned, mine, by team, by label, by status, by priority
- Keyboard driven — a support inbox is used all day and the mouse is the slow part
- Private notes alongside replies, visibly different, never sendable by accident
- Canned replies by shortcut with variable substitution, inserted at the cursor
- Assignment manually or round-robin within a team, with availability respected
- Merge two conversations from the same person, keeping both histories

THE HELP CENTRE
- Collections and articles in Markdown, public, searchable, with its own sitemap and canonical URLs
- Search the articles from inside the widget and send one into the conversation
- Failed searches recorded — an empty result is a request for an article
- Was this helpful, counted per article

MEASURING
- First response time, resolution time, conversations per agent, by day and by hour
- Computed at query time from the events table, never stored as totals
- SLA breaches visible before they happen, not reported afterwards

OPERATIONS
- .env: DATABASE_PATH, STORAGE_PATH, BASE_URL, SMTP_URL, IMAP_URL, WIDGET_JWT_SECRET, SESSION_SECRET, HASH_SALT
- Migrations on boot, each once
- Attachments scanned for type by content, stored outside the web root, served through a signed URL
- Nightly backup off the machine, restore script
- Health endpoint that checks both mail directions

WHAT MATTERS MOST
Email threading and the bounce filter. Build those first and point a real address at it for a week — chat is a straightforward append-only list, but an inbox that splits a customer's thread in three, or that replies to its own bounces, is unusable from the first day.

Give me the repository, the widget script, migrations, .env.example, a seed inbox, and a README with deploy steps behind Caddy and the DNS records for mail.