OperantSolo publishes practical n8n workflows, tutorials and troubleshooting for solo operators and small teams. This policy explains how to read our test notes and how we keep research, tested demos and commercial products clear.
What a tested workflow means
A test note should identify the n8n version, the inputs used, the expected result and what happened. Screenshots and downloadable files should match the tested example. A sample run does not prove that a workflow is ready for every live system.
Research and proposed designs
Some articles explain a design using official documentation. We label these as research or proposed setups when we have not run the exact workflow. Older reviews and comparisons remain in the archive; they are not a claim that every tool was tested in production.
Before using a download
Read its setup guide, test with sample data and check the output before connecting live services. Credentials are not included. Each workflow should state its limits, including duplicate checks, retry behaviour and external services it needs.
Affiliate links and paid packs
Some links may earn us a commission. We disclose partner links near the relevant recommendation. We also sell workflow packs. Product pages explain what is included, what was tested and what buyers need to set up themselves. Payment does not turn an untested design into a tested workflow.
Corrections
Tools and APIs change. If an instruction is outdated or a test result cannot be reproduced, contact hello@operantsolo.com with the page URL, n8n version and the step that failed. Remove passwords, tokens and private customer data from anything you send.
Testing method and update dates
Read How I test for the meaning of a pass, failure injection and the limits of a lab. Record n8n versions per test. Label an unrun adaptation “Adaptation, not tested.” Visible article update dates should match the recorded modification date; do not backdate a new claim or treat a formatting change as a new lab test.