One small tool, one small problem
Repeated copying, hunting for links and formatting text are good starting points for deciding which tools deserve to be built and kept.
An interesting little tool can often be explained in one sentence: organize this text, find that link or save me a copy-and-paste mistake. It does not always need an ambitious product strategy.
Small still deserves care. A tool used for a few seconds can create far more work if its defaults, units or saving behavior are unclear.
Look for a recurring small frustration
Suppose processing a piece of information requires opening three pages, copying two fields and manually fixing the format. That repeated path is a more concrete starting point than “build a platform.”
Write down the input, desired output and most annoying step. If a bookmark, template or short script solves it, start there.
I would ask whether the problem repeats, has a clear completion point and saves more effort than maintaining the tool requires. For a rare problem, a short note explaining the solution may be enough.
Make the first version comfortable to try
A text utility can preview its output before the user copies it. A file-changing tool should explain which files it will affect and provide a way to recover.
Defaults need explanation too. Time zones, monetary units, encoding, spaces and line breaks may sound like implementation details, but they determine whether the output is usable.
I like tools with a visible input, transformation and result. Empty input, invalid formatting or out-of-range values should produce a specific explanation instead of an apparently successful blank result.
Use it before deciding how much it should grow
A formatting utility does not immediately need accounts, and a link page does not have to become a publishing platform. Let actual needs for storage, collaboration or permissions inform the next step.
Watch where manual corrections keep happening, where another person pauses to read instructions and whether the tool remains understandable a week later.
If supporting one new scenario makes everyone fill in five extra fields, I would consider whether it belongs in a separate tool. The cost of a feature lives in every future visit as well as in the code.
Leave a simple instruction card
A tool worth keeping should explain who it serves, what goes in, how to use the result, where data is processed and its known limitations. Examples should use fictional information rather than sensitive material copied into a demonstration.
Sometimes the tool does not need to be built at all. A well-organized set of official platforms and documentation already reduces time spent searching.
The tools section here currently provides those links; it is not a collection of working online processing utilities. Any future small project should start by making its one useful job clear.
If you have a recurring little frustration that you never quite get around to solving, the problem itself is a good reason to start a conversation.