Every product I've shipped started as something I built for myself.
CacheBash wasn't designed to be a product. It was designed to solve a specific problem: I was running multiple AI sessions simultaneously, and none of them could talk to each other. I needed task queues, message passing, and persistent memory across sessions. Nothing existed that did this over the MCP protocol. So I built it.
That was three months ago. Now it's an open-source MCP server with 34 tools across 9 modules, a mobile app for monitoring and approvals, and a roadmap that points toward something bigger than a side project.
Taking an internal tool to open-source product to commercial infrastructure will cost you things nobody mentions upfront.
The Internal Tool Trap
Internal tools are optimized for the person who built them. They have assumptions baked in: how the system is deployed, how many users exist (one), what the error handling needs to be (minimal). They work perfectly in their original context and fall apart the moment someone else tries to use them.
CacheBash had all of these problems. Authentication was a single shared API key. Session management lived in process memory on a serverless platform, which meant it crashed every 20 minutes. Error messages assumed you understood the internal architecture. There was no onboarding flow because the only user didn't need one.
The first decision when you productize an internal tool is what to fix first. Not "make it perfect." That's the enemy of shipped. You need the minimum set of changes that let someone else run it without you standing over their shoulder.
For CacheBash, that list was:
- Per-identity API keys (SHA-256 hashed, never stored in plaintext)
- Structured error responses with correlation IDs
- A configuration format that fits in 3 lines of JSON
- Documentation that explains what the tool does before explaining how it works
That last one is harder than it sounds. When you've been building a tool for months, you forget that "MCP server for multi-agent coordination" means nothing to someone who hasn't experienced the problem.
Three Layers
The architecture that made CacheBash portable is a three-layer separation:
Layer 1: The kernel. Cloud Run + Firestore. Task dispatch, message relay, session tracking, authentication. This is the infrastructure. It doesn't know or care what client connects to it. It speaks MCP protocol and REST.
Layer 2: The SDK. An npm package that wraps the API. This is what external users install. Versioned, changelogged, documented. The surface area that people interact with.
Layer 3: The host integration. Whatever bridges the AI client to the server. Today that's tmux for local development, with a configuration file for each MCP client. Tomorrow it could be Docker containers, CI runners, or cloud VMs.
Each layer is independently replaceable. You can swap Cloud Run for another hosting platform without touching the SDK. You can replace the tmux integration with Docker without changing the API. You can build a different SDK in a different language and the kernel doesn't notice.
This separation wasn't in the original design. The original was a single Node.js process that did everything. The three-layer split happened when I realized that "works for me" and "works for others" require fundamentally different architectures. The internal tool can be a monolith. The product can't.
Zero Friction or Zero Users
The install experience determines whether anyone makes it past "I'll try this later." Every friction point between discovery and first use is a user who never comes back.
CacheBash installs in three lines:
{
"mcpServers": {
"cachebash": {
"url": "https://your-instance.run.app/v1/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_KEY"
}
}
}
}
Add this to your MCP config. Restart your client. Create a task in one session. Claim it in another. Two sessions, coordinated. No custom scripts. No Docker setup. No account creation flow.
Client compatibility matters as much as ease of install. CacheBash uses Streamable HTTP transport with Bearer token auth. That combination works with Claude Code, Cursor, VS Code with Copilot, and Gemini CLI. Four out of five major MCP clients, no backend changes needed. ChatGPT Desktop requires OAuth 2.1, which is on the roadmap but not shipped yet.
The decision to support multiple clients from day one was deliberate. An MCP server that only works with one client is a feature of that client. An MCP server that works with any client that speaks the protocol is infrastructure. I wanted infrastructure.
The Kafka Playbook
Kafka started as LinkedIn's internal messaging system. It solved a specific problem for a specific team. Then it was open-sourced. Then Confluent built a commercial product on top of it. The internal tool became the protocol. The protocol became the platform.
CacheBash follows the same arc, at a much smaller scale.
Phase 1 was the internal tool. Task queues, relay messaging, session tracking. Enough to coordinate my own AI agents. Rough edges everywhere.
Phase 2 is structure. Per-program authentication, target enforcement, delivery confirmation, audit logging. The system becomes trustworthy enough that you'd let someone else's agents connect to it.
Phase 3 is capability. Sprint orchestration with wave-based scheduling. Push notifications for human-in-the-loop decisions. Autonomous overnight execution with budget caps. The features that make a coordination server into a coordination platform.
Phase 4 is surface. A web dashboard for monitoring. A CLI tool for power users. Event sourcing for full replay capability. Three interfaces (phone, browser, terminal) into the same underlying system.
Each phase makes the product useful to a wider audience. Phase 1 serves the builder. Phase 2 serves the team. Phase 3 serves the organization. Phase 4 serves anyone building agent systems.
What Nobody Tells You About Open Source
Open-sourcing a product sounds like a distribution strategy. It is. But it's also a commitment to maintain something you no longer fully control.
The moment you publish a repo under MIT, every API change is a potential breaking change for someone you've never met. Every design decision becomes a public contract. Your internal roadmap is now a public promise.
Things I underestimated:
Documentation is the product. Not the code. The code is what runs. The documentation is what gets adopted. A well-documented mediocre tool will outperform a brilliant tool with a README that says "see examples." I rewrote CacheBash's docs three times before they were good enough to let someone succeed without a Slack conversation.
Issue triage is a skill. Not every feature request is a feature. Not every bug report is a bug. Learning to say "this is a great idea, and we're not building it" without discouraging the person who suggested it takes practice.
Versioning discipline. Internal tools can make breaking changes whenever. Products can't. Semantic versioning isn't bureaucracy. It's a communication protocol between you and everyone who depends on your code.
The gap between "it works" and "it's a product" is mostly invisible work. Error handling. Edge cases. Consistent response formatting. Loading states. Timeout behavior. Graceful degradation. None of this is interesting. All of it is mandatory.
What's Hard Right Now
CacheBash is production-stable for its primary use case: coordinating multiple AI sessions through a single MCP server. The task queue works. The relay works. The session management works. Sprint orchestration with wave scheduling works.
What's hard is the gap between "this works for a few power users" and "this works for anyone who finds it on GitHub."
OAuth 2.1 support would unlock ChatGPT Desktop, but implementing it properly (not just wrapping Bearer tokens in an OAuth flow) takes focused work. Webhook integrations for Slack and Discord would make the alert system useful for teams, not just individuals. GitHub sync so tasks mirror to Issues automatically would reduce the friction of adopting CacheBash alongside existing workflows.
Each of these is weeks of focused effort. The list grows faster than the capacity to build it. That's the defining constraint of a side project turning into a product: the problem space expands while the build team stays the same size.
The Bet
The bet behind CacheBash is that multi-agent AI coordination is going to be as fundamental as version control. Every development team will run multiple AI sessions. Those sessions will need to share state, pass tasks, and coordinate without a human playing switchboard operator.
Right now, that coordination layer doesn't exist as a standard. MCP is the protocol. CacheBash is one implementation. Others will follow. The question is whether the patterns we're discovering (task lifecycle management, relay messaging, persistent agent state, fail-open compliance) become the expected primitives of multi-agent infrastructure.
I think they will. But I thought the same thing about three previous side projects that didn't go anywhere. The difference this time is that I'm using the product every day, it's already solving a real problem, and the problem is getting bigger as AI agents get more capable.
That's usually enough.
CacheBash is open source under MIT. Self-hostable on GCP. The server, mobile app, and all 34 tools are in the repo.