A few notes.

Keep small tools simple

A small tool often starts with a small problem: organizing a batch of files, converting some data, or saving a few repeated clicks. Describing that problem clearly is a better first step than choosing a technology stack.

Before building, write down three questions:

1. What goes in, and what should come out?
2. What does success look like, and when should the tool stop?
3. If it could do only one thing, what would that be?

Clear boundaries make it easier to decide what is needed now and what can wait until a real need appears. A small tool earns its place by doing that one thing reliably.

If it is worth repeating, write it down

When a task is fresh in your mind, its details can seem too obvious to write down. Come back to it a few weeks later, and the same small questions often appear again.

A useful record does not need to be long. Note what to prepare, which steps to follow, and how to confirm the result. That is often enough to make the next attempt easier.

When something unexpected happens, add the reason and the fix. A checklist gradually becomes a record of experience, with enough context to be useful. The best instructions still work after you have forgotten how you wrote them.

Leave some context in the code

Code usually shows what happens, but it does not always explain why. When several approaches could work, the constraints behind a choice can disappear during later changes.

A comment that explains a reason is more useful than a line-by-line translation of the code. Why does this operation retry? What does that branch protect? Which failure made this extra check necessary?

Clear names describe the behavior. A short note preserves the decision behind it. Leaving a clue for the next reader is also a kindness to your future self.