Building it yourself still costs something
Whenever someone says you can just build a tool yourself now, I have two reactions. The first is excitement, because more of those ideas are becoming possible. The second is a small accounting question: what are we including in the cost?
In a draft reply, I listed tokens, time, and running costs. It was a fairly ordinary objection to a very exciting possibility. Being able to make the thing doesn't settle whether I want to be responsible for it.I always forget upkeep
I think the decision will keep moving. Something that is too expensive or frustrating to build today might become a reasonable afternoon project later. Something that looks cheap in a demo might become a surprisingly demanding part of your week.
The first working version has a very good sales pitch
A small tool that does exactly what you asked is persuasive. It doesn't have the extra screens you never use. You can change the wording, remove a step, or arrange the information around your own habits. There is a real appeal in having software that fits without asking someone else to prioritize your request.
But the first version is also the point where you know the least about living with it. Consider a simple tool that pulls information from another service. Getting the information onto a page might be straightforward. What happens when the connection stops working, the data arrives late, or you need to understand a result you didn't expect?
Those questions don't make the project a bad idea. They belong in the decision. If I only compare the subscription price with the cost of generating the first version, I'm leaving out a lot of the work I may be agreeing to do.
Your attention belongs in the calculation
Time is the cost that's easiest to wave away when building is fun. An evening spent exploring a tool can be worth it on its own. I don't need every experiment to justify itself as a saving. Learning something and enjoying the process are perfectly good reasons to make software.
I do want to distinguish that from replacing something I depend on. If a tool supports my everyday work, maintenance competes with that work. Even a quick fix requires me to notice the problem, remember how the project works, and check that the correction holds up.
Paying for a product can mean paying someone else to carry those concerns. Whether they do that well is another question, but it's part of what the price is supposed to cover. The comparison gets more useful when I include the responsibility on both sides.
Make the decision small enough to revisit
For a narrow personal need, I'd be more willing to build something small and see whether I actually use it. The scope gives me a way to learn without committing to recreate an entire product. If it turns out to need constant attention, that's useful information too.
I'd ask what happens if I stop maintaining it. Can I get my information out? Can I return to the previous tool? Does a broken version interrupt something important, or does it just mean an experiment has run its course? Those answers change how much uncertainty I'm comfortable taking on.First question now: can I get my data out
The incentive will keep shifting as the tools change. I want to stay open to that without treating every new capability as another thing I should now own. Sometimes building is the right use of an afternoon. Sometimes paying for the tool is what gives me the afternoon back.
Acknowledgements
Expanded from a reply I drafted about tokens, time, and running costs. The accounting is mine, and it changes every time the tools do.