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. 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 think about your own problem.

That gap is where personal tooling solves something. My lawnops server knows my zones because I encoded them. The zone numbers map to real areas of my yard. 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, because they are mine.

The maintenance cost is real. APIs change, dependencies rot. Maintaining a tool forces me to keep understanding the domain it models. Owning the tool means I never get to stop understanding the domain it models.

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. 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.