Crisp

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 support inbox that replaces Crisp — and know why this is ALMOST.

The inbox and the chat widget are ordinary work. What you are paying for is **flat pricing however many agents you have**, plus channels beyond chat — email, and the messaging platforms, each of which needs an approved application. The pricing advantage disappears the moment you run it yourself, which is the argument for building. The messaging platforms are the part you may not be able to have.

STACK
- Node 20+ with Fastify, server-rendered HTML with a little vanilla JS
- SQLite through better-sqlite3, WAL mode, with FTS5
- 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, 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
- email_threads: conversation_id, message_id_header, references_json
- canned_replies: id, shortcut, title, body_md
- events: id, conversation_id, kind, actor, at — append-only, and the basis of every metric
- attachments stored by hash with the type from content

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

THE WIDGET
- One script, one init call, optionally with a signed identity token from your product so a known user is not asked who they are
- Delivered by polling a small endpoint with a backoff — faster while the conversation is active, slower when 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 in the README where that stops being true
- Offline: when nobody is available it says so honestly and takes an address, rather than pretending
- Full history for an identified visitor, so nobody starts again on every page
- Shadow DOM, keyboard operable, focus trapped, Escape closes, works at 320px
- Typing indicators and read receipts only if they are real. A fake one is a small lie people notice

THE INBOX
- One list with filters: unassigned, mine, by status, by priority, by channel
- Keyboard driven, because this is used all day and the mouse is the slow part
- Private notes visibly different from replies and impossible to send by accident. That confusion is the failure customers see
- Canned replies by shortcut with variable substitution
- Merge two conversations from the same person, keeping both histories

CO-BROWSING, HONESTLY
- Screen sharing and co-browsing are what the higher tier sells and they are a real project — a session relay, consent, and masking of everything sensitive
- The cheap ninety per cent is a "send me a screenshot" flow with an annotation tool, or a link to a meeting service. Start there

MEASURING
- First response time, resolution time, conversations per agent, by day and hour, computed at query time from events
- Never stored totals

OPERATIONS
- .env: DATABASE_PATH, STORAGE_PATH, BASE_URL, SMTP_URL, IMAP_URL, WIDGET_JWT_SECRET, SESSION_SECRET, HASH_SALT
- Migrations on boot, each once; nightly backup off the machine, restore script
- Health endpoint checking both mail directions

WHAT MATTERS MOST
Email threading and the private-note distinction. Point a real address at it for a week — chat is an append-only list, but an inbox that splits a customer's thread in three is unusable from the first day.