Evidence before recommendations

A replacement is useful only if it can do the job you need. Our guides will make the evidence behind that decision visible.

1. Establish what actually changed

Start with official announcements, support documentation, and other primary sources. Confirm whether a product is retiring, a feature is changing, or availability depends on an account or platform. Record a retirement date only when the evidence establishes it.

2. Define the job and constraints

Identify what people used the original product to do. Separate essential capabilities from conveniences. Note the relevant operating system, browser, integration, file format, and account requirements before selecting candidates.

3. Check each alternative

• Platform support: confirm the specific supported platforms and versions.
• Features: check the capability needed for the use case, including plan restrictions.
• Pricing: check the official pricing page and record currency, billing period, and verification date when stating a price. Omit unverified prices from published comparisons.
• Limits: identify quotas, upload limits, privacy considerations, and other relevant constraints.
• Migration: document export and import support, setup requirements, and anything that may not transfer.

4. Separate evidence from judgment

Documented facts cite the source. Hands-on results describe what was tested, on which platform or plan, and when. Editorial judgments explain the trade-offs and who the recommendation is for. Documentation does not count as a hands-on test.

We will not fill gaps with invented rankings, review scores, performance claims, or user testimonials.

5. Publish with a verification date

Each published replacement guide must include primary sources and a last verified date. The last updated date records an editorial change; it does not by itself mean the underlying facts were rechecked.

Incomplete content remains a draft excluded from production, or is excluded from indexing. Before publication, an editor must review the sources and confirm that the conclusions are supported.

6. Revisit and correct

Software changes after a guide is published. When a material change is identified, recheck the affected claims, revise the guidance, and update the verification date only after those checks. There is no fixed rechecking schedule promised at launch.