Most of the work I build begins in a surprisingly similar place. It is rarely a fully formed concept with an obvious destination. More often, it starts as a question that continues to surface, an observation that seems worth exploring or a recurring problem that appears in different contexts. At that stage, I am usually less interested in deciding what to build than in understanding why the idea continues to return.
Earlier in my work, I often made that decision too quickly. An interesting concept became a software project because I wanted to build something. An useful observation became a blog post because writing was the fastest way to publish it. Sometimes those choices worked but just as often they resulted in projects that felt incomplete because the format never matched the idea itself.
Over time, I realized that deciding what to build is often easier than deciding what form the work should take. That distinction has become one of the most important parts of my process. Rather than asking whether an idea is good enough to pursue, I spend more time asking what the idea is actually trying to become.
Different Ideas Solve Different Problems
One pattern I have noticed is that ideas naturally fall into different categories, although those categories are not always obvious at first.
Some ideas primarily improve understanding. They help explain relationships, organize observations or clarify concepts that were previously scattered. Those ideas generally belong in writing because the value lies in the reasoning itself. The finished article becomes a record of thinking rather than a description of a finished product.
Other ideas reveal repeated work. If I find myself performing the same task across multiple projects, the problem is no longer a lack of explanation but a lack of reusable infrastructure. In those situations, writing another article rarely changes anything. A tool or library is often the more durable response because it removes repetition instead of documenting it.
There are also ideas that extend beyond either category. They represent something that people can continuously use rather than simply understand. Those ideas sometimes evolve into products because they require maintenance, refinement, and ongoing interaction rather than a single explanation or implementation.
Recognizing these differences has helped me avoid forcing ideas into formats that do not naturally fit them.
Writing Helps Me Understand
I often think of articles as exploratory rather than definitive.
When I write, I am usually trying to understand how different observations connect rather than prove a conclusion. Writing slows thinking down enough that assumptions become visible. Connections that seemed obvious often require refinement once they are expressed clearly.
This is one reason I continue writing even when I expect an idea to evolve into something larger. The article creates a snapshot of the current understanding. It establishes vocabulary, clarifies boundaries and exposes unanswered questions. Those questions frequently become the foundation for future work.
Several projects have followed this pattern. An article identifies a recurring challenge. Continued work reveals a broader structure. Eventually that structure becomes a specification, dataset or software project. Looking back, the article was never the finished product. It was the first stage of understanding.
Because of this, I no longer see writing as separate from building. In many cases, writing is part of the design process itself.
Tools Reduce Friction
The decision to build a tool usually comes from repetition rather than inspiration.
Whenever I notice myself solving the same problem across multiple repositories or rebuilding similar workflows, I begin questioning whether the work should exist as reusable infrastructure instead. The objective is rarely automation for its own sake. Instead, it is about reducing unnecessary decisions so more attention can be directed toward problems that genuinely require thought.
This perspective has influenced much of my recent work. Templates, validation utilities, datasets, APIs and shared documentation all emerged because similar needs appeared repeatedly across otherwise unrelated projects. Individually, those needs seemed minor. Collectively, they pointed toward an opportunity to simplify future work.
A useful tool often solves a narrower problem than an article discusses but it usually solves that problem more consistently. It transforms recurring effort into infrastructure that can support many projects rather than just one.
Products Require a Different Commitment
Products occupy a different place in my thinking because they create responsibilities that articles and tools often do not.
Publishing an article is primarily an act of communication. Releasing a tool introduces maintenance but that maintenance can often remain relatively contained. A product, however, creates an ongoing relationship with the people who depend on it. Documentation, reliability, support, versioning and long-term evolution become inseparable from the original idea.
For that reason, I have become more selective about turning projects into products.
The deciding factor is rarely whether the idea could generate interest. Instead, I ask whether it deserves continued stewardship. Some ideas benefit from remaining open repositories or research initiatives because their primary value comes from collaboration and exploration. Others justify becoming products because they solve recurring problems that require consistent refinement over time.
This distinction has become increasingly important as the number of active projects has grown. Every product introduces long-term obligations and those obligations deserve as much consideration as the original idea itself.
One Idea Can Have Multiple Forms
Although I often think in terms of articles, tools and products, I no longer view these as mutually exclusive outcomes.
A single idea frequently moves through several forms as it matures.
An observation may first appear as an essay that explores its broader implications. Continued research may expose patterns that justify collecting structured data. That dataset may reveal opportunities for a reusable library or API. If the underlying problem continues to appear across different contexts, the work may eventually evolve into a maintained product.
Viewed individually, each stage appears to be a separate project. Viewed collectively, they represent the gradual refinement of the same underlying idea.
This perspective has influenced how I organize my work. Rather than expecting every project to become something large, I allow ideas to develop at their own pace. Some remain articles because explanation is the appropriate endpoint. Others become tools because the practical value outweighs further discussion. A smaller number continue evolving because they reveal broader opportunities over time.
The destination is determined by the idea itself rather than by an expectation established at the beginning.
Building Around Questions Rather Than Formats
One of the most useful changes in my thinking has been shifting attention away from outputs and toward questions.
When I begin with the assumption that I should build a product, I naturally search for features. When I assume I should write an article, I look for arguments. When I expect to create a tool, I focus on implementation.
Those assumptions shape the work before I fully understand the problem.
Beginning with the question instead creates more flexibility. It allows the eventual form to emerge from repeated observation rather than from an early commitment to a particular format. Sometimes that means concluding that the best outcome is simply a well-considered article. Other times it reveals a need for infrastructure that would never have become obvious through writing alone.
Allowing ideas to remain unresolved for a while has made the eventual decisions more durable.
Building What the Idea Actually Needs
Looking across the different repositories, publications, datasets and initiatives I maintain, I no longer think of them as belonging to separate categories. They are different expressions of the same underlying process of exploration.
Some ideas need explanation before they need implementation. Others need infrastructure before they need discussion. A few require ongoing stewardship because they continue creating value long after their initial release.
The challenge is not deciding whether an idea is important enough to pursue. It is deciding what form allows that idea to contribute most effectively over time.
That question rarely has an immediate answer and I have become comfortable with that uncertainty. Waiting until the shape of an idea becomes clearer has consistently produced work that feels more coherent, more maintainable and more connected to everything that came before. For me, that continuity matters far more than choosing the fastest path from idea to publication.
