The Case for Owning Your Own Tooling
I run eleven MCP servers that I wrote myself. Home operations, lawn care, budget, flight prices, calendar, network, DNS, mail. All Python, all FastMCP, all wired into my Claude Code setup. Alongside those, forty-five-plus Ansible roles and a TypeScript plugin for session context. None of this was a weekend project. It accreted over years.
The argument against building your own tooling is the obvious one. Someone already built it. It is maintained by a team, it has a support contract, and you can stop thinking about it. Most of what I use day to day is somebody else’s software, and it should be.
A vendor builds for the median user. They have to. The product has to make sense to the largest reachable group of people, which means it is shaped around the average case and the average mental model. Then it is optimized for retention, because that is the business. Neither of those forces is aligned with how you specifically think about your own problem.
That gap is where personal tooling earns its keep. My lawnops server knows my zones because I encoded them. The zone numbers map to real areas of my yard, and the tool speaks that language because I taught it to. My ynab tooling knows my categories because they are my categories. The fit is exact because I am the one who defined both sides of it.
And that fit compounds. Every time I extend a tool I have built, I am extending something already shaped to how I think, so the next feature drops into place instead of fighting the existing model. Six years in, they fit better than anything I could have bought, not because they are more sophisticated, but because they are mine.
The maintenance cost is real. APIs change, dependencies rot. People treat that as the tax. It is not. Maintaining a tool forces me to keep understanding the domain it models. Owning the tool means I never get to stop understanding the thing it touches.
Building your own is worth it when the problem is yours specifically, when you will use it often enough to amortize the maintenance, and when the fit between the tool and your mental model is what actually matters. That last one is the real test. If the median solution fits you fine, buy it. If you keep finding yourself working around the tool to get to your actual problem, you already have your answer.