I Built Helm Instead of Buying It. I'm Not Open-Sourcing It Either.
Someone sells a terminal workspace tool for around $100/yr. I built my own in an afternoon. I'm not putting it on GitHub, and that decision is the part of the build/buy story most people skip.
I found a Mac app that does roughly what I need: one window, terminal multiplexing, MCP hooks for agents, a project sidebar. It’s priced around $100 a year. I sat with it for maybe twenty minutes, decided the customization I wanted wasn’t worth waiting for, and built my own version in an afternoon.
I use it every day now. It’s called helm. It’s not on GitHub.
The “I built it in an afternoon” story is now common enough that it doesn’t really say anything on its own. The part I think is more interesting is the second decision: once you’ve built the thing, what do you do with it? Most of the AI-builder discourse stops at “now you can build whatever you want.” It skips the question of whether you should publish what you built when there’s already a person making a living selling something similar.
What helm is
For context, helm is a Tauri + xterm.js native app. The left side is a project sidebar with collapsible sections for agents, commands, and terminals. The right side is a real PTY-backed terminal. Pick a process, you’re typing into it. Each project lives in its own helm.yml file at the repo root, defining what processes auto-start, which file globs trigger restarts, and which commands count as agents vs. commands vs. shells. There’s an MCP server on localhost so Claude Code or Codex can query what’s running, read terminal output, and restart things when they crash.
It’s roughly 4,000 lines between the Rust backend and the TypeScript frontend. The first version came together in an afternoon. Then I spent a few evenings polishing: keyboard navigation, a command palette, settings, git status polling, the ability to spawn agents on the fly. None of this is novel. The MCP server is genuinely useful and not something I’ve seen elsewhere, but the core (“terminal multiplexer with project awareness”) is well-trodden ground.
Why I built it instead of buying
The buy/build line used to be obvious for something like this. The existing tool costs $100 a year. Building it from scratch would have taken weeks: UI work, PTY multiplexing, process lifecycle, config schema, the whole stack. Even at a high hourly rate, the math says buy.
That math doesn’t hold anymore. With Claude doing most of the plumbing (Tauri scaffolding, xterm.js wiring, PTY handling, the dance of streaming bytes from the backend to a terminal in the frontend), what would have been weeks became hours. Most of what I did was decision-making and review. “Is this the right way to model process state?” “Does this keybinding feel right?” “Does this MCP tool name read well?” Those questions don’t speed up with AI, but they’re a much smaller share of the total work than implementation used to be.
The customization piece mattered more than the cost. The existing tool ships with someone else’s opinions about defaults: keybindings, sidebar layout, what processes get grouped where, what shows up in the command palette. Even if I’d paid for it, I’d want it different. Building meant I got the version I’d actually wanted from the start. Auto-restart with the exact backoff curve I prefer. MCP server speaking the exact tool shape my agents use. Sidebar grouping that matches how I think about a project (agents, commands, terminals as three separate sections, not one mixed list).
The new math is “an afternoon vs. $100/yr plus living with someone else’s defaults.” For almost any tool in the single-developer productivity category, that math now favors building.
Why I’m not putting it on GitHub
Here’s where it gets less obvious.
The natural next move after “I built a thing and it works” is to publish it. Push it to GitHub, write a README, maybe a launch post. That’s how the tech-builder cycle has worked for a long time: you build, you share, you get stars, you get hired or get pull requests or both. The whole open-source ethos is built on this loop.
I’m not doing it for helm. The reason is straightforward: the person selling the $100/yr tool is a real person who got there first, built a real product, and is making real money from it. If I open-source a free, MCP-aware version with most of the same features, I’m directly undercutting their market. Not as a side effect, the most likely outcome. The differentiation between “$100/yr proprietary Mac app” and “free MIT-licensed tool that does the same thing and works better with AI agents” isn’t subtle. People would switch.
The fact that I could build it cheaply and could publish it doesn’t mean I should. AI made it possible for me to recreate someone else’s product in an afternoon. It didn’t make it ethical for me to then put that product on GitHub and watch them lose customers. The market they built took years. My recreation took a day. That asymmetry is the whole problem.
I want to be specific about what I’m not claiming. I’m not claiming this is some universal rule. Big companies clone open-source tools all the time and the ecosystem absorbs it. Cursor exists in a market with VS Code. Linear exists in a market with Jira. Competing in established markets is fine. What I’m claiming is narrower: when an individual developer with no business to protect can vibe-code a clone of a small creator’s product in an afternoon, publishing that clone is shitty. Different scale, different math.
There’s also a self-interested angle. I want a world where small creators can still make a living building niche dev tools, partly because I might want to be one of them. If the new norm becomes “anyone can clone your product in a day and ship it for free,” the incentive to build niche dev tools as a real business approaches zero. I don’t want to live in that world, so I’m not contributing to making it.
When the new math says “build”
A few patterns I think about now when deciding whether to build instead of buy:
Heavy customization is the goal. If I want the thing shaped my way more than I want it solved fast, building wins almost every time. The cost of building isn’t “the time it takes to build” anymore, it’s “the time it takes to define what I actually want.” That’s work I’d have to do regardless.
Single-user scope. No multi-user state, no auth, no payments, no compliance. The hardest parts of most products are the parts that touch other humans (billing, permissions, abuse prevention, support). If I’m the only user, those go away.
An open ecosystem to plug into. Helm makes sense to build because Tauri exists, xterm.js exists, the MCP spec exists. I’m gluing existing parts together with strong opinions, not inventing the parts. When you have to invent the parts, you’re back to “this is a real product, not an afternoon project.”
No need to evolve at the speed of a market. A SaaS tool gets weekly feature drops because customers expect them. My personal tool just needs to keep working. I can leave it alone for six months and it doesn’t get less useful.
When any of these don’t hold, I still buy. I pay for tools where someone else is solving the actually hard problem (Linear for issue tracking, I’m not building that), where the value is in the network or the data (1Password, also not building that), or where I’d have to maintain something I’d rather not think about.
When “build privately” makes sense
This is the new category that the AI-builder discourse mostly skips. There’s “build for yourself,” “build for everyone,” and now there’s a third option that’s becoming more common: “build for yourself, don’t publish.”
A few patterns I think trigger the third option:
Direct substitute for a small creator. What I described with helm. If shipping my version most likely takes meaningful customers from one identifiable person, I keep it private.
Reimplementation of a paid tool with no real differentiation. If the only thing my version does that the paid version doesn’t is “free,” I’m just a freeloader who decided to publish my freeloading. Skip it.
Free client for a service whose business depends on its official client. Different kind of shitty than the helm one, but it lives in the same neighborhood. Even if it’s technically allowed, it’s parasitic.
I’m fine publishing things that don’t fit those patterns: my own original ideas (Orch, Scry, Trawl, Cockpit), tools that fill genuine gaps in open source, plugins to existing FOSS projects, weird experiments. Helm doesn’t fit. Helm is “I rebuilt a small business’s product because I could.” That stays on my machine.
Where helm lives now
Helm runs on my laptop and on the laptops of two friends I shared the binary with privately. There’s no GitHub repo, no install script, no Hacker News post. If the original creator ever reads this, sorry for not paying $100 a year, but the customization piece really did matter, and the version I want doesn’t exist on the market. Either way, your customers are still your customers.