Most useful software starts as an observation, not a repository. Before I write code for a new tool, I try to answer a smaller question: is there enough repeatable demand to justify building and maintaining it?

This is the checklist I use when I want to validate an idea without turning the research phase into a second full-time job.

1. Start with the job, not the feature list

I write down the job in one plain sentence:

Who is trying to do something?