Running costs were one of the reasons I changed the first route considered for Kindred Hands. That made the question of what continues later much more practical. A service might be easy to choose at the beginning, while the reason for that choice becomes harder to explain once other work takes over.
I was responsible for the software setup with mentor support, and the phase took about three months. Kindred Hands was intended as a not-for-profit initiative, so the software choice meant taking on commitments as well as capabilities. Open-source alternatives changed the arrangement; they did not remove the need for someone to understand it. I’m using a renewal below to follow that responsibility over time. The interesting question is what somebody needs to know when a commitment comes around again.
A repeating charge can affect the choice even when the first amount looks manageable. The amount is one part of the question. The other part is the job that depends on it, and whether somebody else will understand why that job was arranged this way.
For a simple example, suppose a function depends on a service that renews each year. At the start, the reason for using it is obvious to the person setting up the site. They have just compared the choices and know what problem it solves. Later, somebody sees a payment request with a product name rather than the explanation. The name alone may not tell them what would stop working if they chose not to continue.
There are at least two separate questions hiding there. Do we still need the job done? And is this still the right way to do it? If the answer to the first question is yes, cancelling something without understanding its role could create more work. If the answer is no, continuing only because nobody remembers the original reason would also be a poor decision. A reminder to pay is less useful than a short note explaining what the service is for.
The timing can matter as much as the amount. A few services renewing at different times could be harder to follow than one larger commitment that everybody understands. I’m not saying our setup has that particular pattern. It’s a reason to look at the dates alongside the prices instead of adding all the amounts into a total and throwing the dates away.
I also need to distinguish access to the software from other things that may come with a plan. Depending on the product and licence, an end date could mean different things for updates, support or features. I can’t assume the same consequence for every tool. The sensible way to know is to check the actual terms of the option being considered. Guessing because another service worked a certain way would be too easy.
This is where the software choice starts to feel connected to the people who will maintain it. If I’m the only person who understands why something is there, they will have to ask me before making an ordinary decision. That might work while I’m already looking at the project every day. It becomes less reasonable if I’m busy or have forgotten the details myself.
The notes do not need to become a massive document to prevent that. A clear explanation of the job, the reason it was chosen, the period it covers and the consequence of stopping would already be more useful than a folder full of screenshots. Screenshots help preserve what was offered at a particular time. They do not automatically explain which part mattered to us.
There’s an interesting connection here with the cost review. A recurring charge is not just an amount to reduce. It’s a decision that will have to be made again. If the organisation understands the reason, it can decide sensibly when its needs change. If it only has a total, the choice may feel like a surprise every time.
I want to be able to discuss that with my mentor without treating every subscription as a mistake. There may be good reasons to pay for something. There may also be good reasons to replace it. I care more about being able to explain the choice than about making the list look as close to zero as possible.
The open-source route will need this kind of thinking too. Removing a software licence does not remove hosting, updates or other continuing work. It changes what needs attention. If I write down only the part we no longer pay for, I could leave the next person with a very incomplete picture of the job.
Another useful question is whether a commitment has an alternative route. I don’t mean keeping a second complete site ready for every possibility. I mean understanding the job well enough that a future decision is about a requirement, rather than only about a brand name. That understanding should survive longer than my memory of the original product page.
So this little question has become a useful test for me. Can I explain the commitment to somebody who has not spent the last few sessions comparing options? If I cannot, I probably need to understand it better myself. I would rather do that now than expect a future version of me to reconstruct the reason from the name on a bill.