Hi HN, Eddie here. My project BigBlueBam is a self-hosted, MIT-licensed Work OS with a unified backend with native MCP, "AI as Users" rather than bolted-on chat widgets. The deploy script will stand up the full stack (local Docker container or push it to Railway) in about the time it takes to make coffee.

What's live in the build: * Bam (project management/Kanban) * Banter (chat with LiveKit voice/video) * Beacon (knowledge base with a graph view) * Brief (collaborative docs) * Board (infinite canvas whiteboard) * Bolt (workflow automation) * Bearing (goals and OKRs) * Bond (CRM) * Blast (email campaigns) * Bench (analytics and dashboards) * Book (scheduling) * Blank (forms) * Bill (invoicing) * Helpdesk

The architectural bet I cared about most: MCP is the execution substrate for the whole suite, not a "feature". 340 MCP tools (and counting) registered across the apps. Agents and Bolt automations call those tools through the same registry, same auth, same data, and the MCP tools replicate any action a user can take in the UI.

Why I built it: honestly, out of annoyance. I wanted my own ticketing+Kanban and I'd started hacking on that and a Slack-alike in my spare time a while back. Recently I picked several old projects back up with Claude Code and started thinking what I'd do differently if I built them from scratch. MCP integration came up because I’ve been doing a lot of smaller MCP Server work, and I got carried away once I saw how much leverage I was getting from the unified data backend + shared MCP tooling. Once that clicked, each new app in the suite was less work than the last, and agents got more capable with every tool I added.

Try it: git clone, run ./scripts/deploy.bat, (or .sh or .ps1), pick Docker or Railway, answer a few prompts, and you're up in a few minutes. MIT license, full source, no telemetry, no feature gates. If you skip setting up a userid/password during install, it’ll have you create a SuperUser account the first time you hit it.

Railway deployment does have a couple minor notes since their graphql API can’t do everything; You can pick up a detailed overview of how that works in docs/railway-runbook.md

What's rough, and where I'd value feedback:

1. Local Docker won’t set up certs for HTTPS, so MCP tools can only be accessed at http://localhost/… 2. Voice and video in Banter works via LiveKit, but I haven't tested it recently and hasn't been pushed into the corners of the suite where it belongs. Treat it as alpha. My intent is that any collaborative space is calling-enabled, ie., “we’re all in the same room” and less like calling is some special thing that you “do over there”. 3. LiveKit agent layer is skeletal today. The next month is focused on standing up real agent participation in voice and video calls, built on local models (I have a lot of background in voice AI.) 4. Service account management is very new and not as granular as I’d like. This is true for human user management as well. Permissions are fairly coarse. It'll get there. 5. Templates of various kinds need to be reworked. A lot has changed underneath them since they were created. 6. Slack and GitHub integration haven’t been used in anything like Production yet. Slack because Banter replaces it so it's low-p for me, and GitHub because I’ve actually got a LOT more I want to do with it. 7. A suite this size needs real users hammering on it. Synthetic data plus a handful of human testers only catches so much. If you spin it up and break something interesting, raise an Issue. That's the most useful thing anyone can do for me right now.

Stack notes for the curious: Fastify v5, Drizzle, React 19, TanStack Query, Redis, MinIO for files, BullMQ for jobs, LiveKit for WebRTC, Qdrant for vector search (picked over pgvector for hard-delete semantics and built-in RRF), Yjs and Hocuspocus for CRDT in Brief and Board, Turborepo monorepo.