Build What
You Know
The best small tools often come from a problem you have lived with directly.
It is tempting to build software from a market map. Pick a category, study the incumbents, copy the expected surface area, and look for a gap. That can work, but it often produces tools that understand the category better than the work.
OpenTrace came from a more practical place: background processes are often important, quiet, and hard to explain while they run. Imports, scrapers, workers, reconciliations, checks, and reports all produce operational questions that logs and infrastructure dashboards do not always answer quickly.
Lived problems have texture
When you know a problem from experience, you know the awkward details. You know which questions people ask in chat, which failures stay silent, which status updates are always late, and which parts of the system operators do not want to reverse-engineer again.
Scope gets clearer
Building what you know helps with restraint. You are less likely to add features because a category requires them, and more likely to keep the product focused on the recurring pain. For OpenTrace, that means making operational work explain itself without becoming a general observability platform.
The first user is real
A known problem gives you a real first user, even if that user is yourself from six months ago. Would this have shortened an incident? Would this have avoided a manual log check? Would this have made a handoff clearer? Those questions keep the product honest.
Knowledge becomes design
The goal is not to build only for yourself. The goal is to let real operational knowledge shape the first version before abstractions dilute it. Good software often starts as a clear answer to a problem the builder understands too well to ignore.