Should you build your own Intercom?

Build a closest honest personal substitute for Intercom in an empty repository.
Use Next.js 15, TypeScript, PostgreSQL, Drizzle ORM, WebSockets, and Docker Compose; do not offer alternative stacks.
The core loop is: receive website messages into a small shared inbox, reply from one place, maintain a knowledge base, and retain searchable history without recreating Intercom's AI or channel network.
Make the first run work locally with one documented command.
Store all user data locally by default and make export straightforward.
Put secrets in .env, ship .env.example, and never commit credentials.
Implement one workspace, agents, contacts, inboxes, conversations, messages, labels, and assignment.
Provide a website chat widget with reconnect, unread counts, file limits, and clear availability state.
Create a shared inbox with filters, collision warnings, notes, canned replies, and searchable history.
Add email notifications, browser notifications, and an immutable assignment and status log.
Implement spam controls, attachment scanning hooks, retention settings, export, and contact deletion.
Ship Docker Compose, backups, health checks, migrations, and a documented admin recovery flow.
Include clear empty, loading, success, and recoverable error states.
Add input validation, safe filenames, and graceful handling of unavailable APIs.
Write focused tests for the core transformation and one end-to-end happy path.
Create a README with setup, architecture, permissions, data location, and backup steps.
Do not add accounts, billing, telemetry, analytics, or a hosted control plane.
Do not claim to reproduce proprietary data, network liquidity, regulated access, or frontier infrastructure.
Deliberately leave out many social and messaging channels.
Deliberately leave out AI agents trained on proprietary support data.
Deliberately leave out enterprise workforce management, SSO, and compliance.
Finish by running the tests and listing the exact commands used.