A method section describes what happened. It rarely includes the small scripts, scheduled jobs, and data-cleaning decisions that made it happen. Those choices are part of the method, even when they never reach the paper.
I like small tools for this reason. A monitor that sends one email when a threshold is crossed is not a research finding. But it is a legible piece of infrastructure: the rule is explicit, the source is linked, and the failure modes are visible.
Inspectable by default
The projects on this site are built around a simple preference: make the smallest thing that answers the question, then document how it works. A scheduled workflow is easier to audit than a dashboard nobody remembers to open.
This is also why the site itself is open source. The design, the content model, and the deployment are not separate from the argument. They are a demonstration of the kind of infrastructure I want research to have: modest, readable, and easy to fork.
A tool becomes method when someone else can inspect it.
Not every tool needs to be public. Some data cannot be. But the default can still be: show the rule, show the source, show the uncertainty. The rest is detail.