Review Methodology
Last updated: August 2026
Most software "reviews" on the web are rewrites of a pricing page. This page explains how Yangworks distinguishes what it has actually run from what it has only read, and what every article is required to publish so you can check the difference yourself.
Two article types, kept apart on purpose
1. Hands-on review or comparison
Published under Reviews and Comparisons. These require that Yangworks actually ran the product — in production, in a real project, for long enough to have opinions that survive contact with the thing. A hands-on article states the version or plan used, the dates of use, and the environment it ran in.
A product Yangworks has not run does not get a review here. There is no "review" of a tool assembled from its own marketing copy.
2. Research guide
Published under Guides. These are structured readings of official documentation, pricing pages, and third-party reporting — useful for a purchase decision, but not evidence of use. A research guide states in its test scope, in plain language, that the product was not operated by Yangworks and that no usage, performance, or cost outcomes were measured.
The Printify article is the reference example: it is thorough, it is commercially motivated, and it opens by saying that no live Printify store was operated and no samples were measured. Depth is not a substitute for having used something, and it is not presented as one.
Field notes
Field notes are first-person records of a change made to a real system — a migration, a rebuild, a decision and its consequences. They are bounded by what the repository and the live site can actually prove, and they say which parts the evidence does not cover.
What every article publishes
Each article on this site carries a method block containing:
- Test scope — what was examined, on what date, and explicitly what was not tested.
- Evidence — the artifacts behind the claims: configuration, commits, generated output, live URLs.
- Sources — official documentation and third-party material, each with the date it was checked.
- Dates — published, last updated, and last tested, shown separately because they differ.
- Disclosure — the article's affiliate status, stated even when it is "none".
- Corrections — how to report an error in that specific article.
These fields are enforced by the site's build: an article missing a test scope, a dated source, or an evidence list fails validation and cannot be published. Draft articles are excluded from the production build entirely and never enter the sitemap.
Claims Yangworks does not make
The following are never published unless they were genuinely measured here, with the method described:
- Performance benchmarks, latency figures, or build-speed comparisons.
- Uptime or downtime claims, including "zero-downtime migration".
- Cost savings, revenue, conversion rates, or traffic and ranking outcomes.
- Duration-of-use claims such as "after six months with X".
- Any statistic derived from a sample Yangworks did not collect and cannot attribute.
Where a third party reports such a number, it is attributed to them and left as their claim. Aggregate ratings are treated as sentiment signals, not measurements.
How comparisons are kept fair
A comparison declares one shared test scope covering both options and applies it to each. Where one side was used in production and the other was only researched, the article says so rather than implying symmetry. Comparisons end with the conditions under which each option wins, because "it depends" is usually the honest answer and the useful part is the on what.
Freshness
Pricing and platform behavior change without notice. Every source carries the date it was checked, so a reader can judge how stale a claim may be. When an article is revisited, the updated date changes and outdated figures are corrected rather than quietly left in place. If you find a figure that has drifted, please report it — see Contact.
The commercial rules that sit alongside this method are on the editorial policy and affiliate disclosure pages.