Future Stack Reviews researches AI tools and SaaS products for buying and usage decisions: what a tool may suit, what using it can cost, where it creates work or risk, and what remains uncertain. This page sets our publishing standards. Read each article for the research actually completed, the evidence behind its claims and any outstanding checks.
Read the scope first
A useful article makes four things clear: the decision and intended user; the work actually performed; the plan, environment and dates relevant to the findings; and the unresolved conditions that could change the conclusion.
Look for the research scope before treating a finding as applicable to your situation. A successful run belongs to the task and conditions checked; it does not establish reliability across other tasks or accounts. A failure also needs its conditions explained. Features outside the stated work remain untested.
Research depth: Tier A, Tier B and Tier C
Research tiers describe the depth of an article, not product quality. They do not certify every claim in that article. The evidence supporting each claim, and whether required checking is complete, must be considered separately.
Tier A — Extended hands-on
Sustained operational use or an extended active test, supported by multiple firsthand observations and source research. The article should identify the duration, workflows, environment and limitations actually covered. Account age or subscription length alone does not establish operational depth.
Tier B — Focused hands-on and research
Actual firsthand work on defined tasks, supported by source research. It requires a suitable usable account or test environment and observations from the work performed. Its bounded scope does not imply long-term use or testing of the whole product.
Tier C — Document research
Research from available sources, without a claim of FSR firsthand product use. It can explain documented options, pricing, terms and open questions without a product account. A Tier C article can stand on its own; it carries no promise of a later hands-on upgrade.
The tier follows research actually completed. Payment, a free or supplied account, trial access and commissioning do not earn a higher tier. A suitable free account, API environment or vendor-provided setup can support firsthand work within its disclosed limits; receiving access alone is not testing.
Starter Guide is the format
Starter Guides explain basic uses, essential terms and practical conditions for readers new to a tool, while remaining useful to experienced readers. Starter Guide · Tier A, Starter Guide · Tier B and Starter Guide · Tier C are all possible. The format describes how the article helps the reader; the tier describes the research behind it. Neither is a product score or membership level.
What supports each claim
Evidence is chosen for the question being answered. The following distinctions describe the support for a claim; they are not a universal best-to-worst source ranking.
- Official sources: what applicable pricing pages, documentation, changelogs or terms state. A vendor performance claim remains attributable to the vendor unless independently established.
- FSR observations: what was displayed or happened in a described check. Identify the account, task, conditions and limitations relevant to the finding.
- Independent reporting: relevant reporting and tests from other identified sources, assessed for their independence, methods, dates, limitations and material commercial relationships. Another person’s test is not an FSR test.
- Calculations and interpretation: what follows from stated inputs, formulas, assumptions or editorial reasoning. An estimated cost is not the amount an account was charged.
- Unresolved or conflicting information: what is missing or disagrees, which sources or conditions are involved, and how the gap limits the conclusion.
For an advertised price, use the relevant plan and pricing documentation. An observed checkout establishes the offer displayed to that account at that time. For product behavior, use records of the task and result. Published data terms describe the vendor’s stated conditions; reading them does not establish actual handling or deletion of data.
A screenshot records what was displayed under particular conditions. A claim about completing a workflow needs the actions taken and their results. Watching a vendor demonstration or receiving screenshots does not establish that FSR performed the task, and a screen observation alone does not earn article Tier B.
Dates, plan, region, version and access conditions matter. Where sources disagree, identify the disagreement, seek clarification where useful and limit the conclusion. Do not silently choose the source that best supports the preferred outcome.
From a buying question to a supported conclusion
Research should follow the decision and the claims the article intends to make. A document-research article follows the source route; claims about firsthand performance require the corresponding product work.
- Define the decision. Identify the intended reader, task, candidate products and conditions that could change suitability.
- Collect applicable sources. Check the relevant pricing, entitlements, documentation, terms and dated reporting. Separate vendor statements from independent findings.
- Identify decisive gaps. Decide what the sources establish, what needs product use and what cannot be concluded within the available access or scope.
- Perform and record scoped work where needed. For Tier A or B, carry out the actual tasks and retain results, failures, restrictions and supporting evidence. For Tier C, keep claims within the source research performed.
- Assess the decision. Compare the findings, costs, practical friction, contradictions and remaining uncertainty. Explain which conditions could change the recommendation.
- Check the claims and conclusion. Identify the research completed, required human checks and publication responsibility. An unfinished check remains pending.
For hands-on work
A hands-on claim requires a record of the product and plan, relevant version and region, date and duration, environment, task, input data, steps, observed result, limitations and supporting evidence. The record must also identify the researcher and the required human-check status. Public examples must protect confidential information and credentials.
Describe failures, manual repair and excluded features as well as successful outputs. If a conclusion relies on repeatability, explain the repetitions and variation actually observed. A single attractive output does not establish reliable performance, and a narrowly tested task does not establish whole-product quality.
What we evaluate
The questions depend on the category and intended work. These lenses explain how a finding can affect a buying decision; they do not imply that every article tested every item.
- Task and output quality. Can the tool complete the named job, and what verification or repair does the output need? For AI tools, relevant questions include factual errors, inconsistent results, format control, editing burden and failure modes. Distinguish observed behavior from advertised capabilities.
- Usable cost and entitlement. Which plan includes the required feature? Consider billing period, seats, usage limits, credits, add-ons, API access and relevant renewal or cancellation conditions. Cost examples need a currency, date and assumptions, with tax or checkout conditions identified if unchecked. Separate advertised prices, estimates and observed charges.
- Setup and ongoing work. Examine onboarding, extra steps, approvals, fragile handoffs and the effort needed to repeat the workflow. A quick demonstration may conceal the work required in routine use.
- Integrations, export and switching. What connects to the existing workflow? What can be exported, in which format and on which plan? Identify conversion work, closed dependencies and switching costs within the declared research scope.
- Documentation, support and account operations. Consider instructions, error messages, account controls, support access and cancellation paths. Reading help pages does not establish response quality; opening a support request does not establish that it was resolved.
- Relevant data and contractual conditions. Examine applicable public policies, permissions, data terms and plan restrictions where they affect the decision. Identify the documents and unanswered questions rather than treating a trust-center page or policy statement as proof of security or compliance.
Limits of the assessment
Research is bounded by its declared scope, available sources and access. It cannot guarantee future prices, availability, vendor continuity, uptime or results outside the work performed. Market coverage is not exhaustive, and public user reports can identify issues worth checking; they do not, by themselves, show how common an issue is.
FSR does not issue security audits, penetration tests, compliance assessments, certifications, assurance opinions or customer-specific legal suitability determinations. Public buying research is not legal, financial, tax, medical or investment advice. Separately contracted corporate work has its own requirements, approvals and delivery terms; confidential customer records remain separate from public research.
Comparisons and recommendations
A comparison should identify its intended user, use case, candidate inclusion and exclusion criteria, relevant conditions and evidence behind any ordering. Differences in test access or research depth must remain visible. Evidence missing for one candidate limits the conclusion; it does not by itself establish inferior product quality.
A document-based comparison can usefully compare documented prices or terms. It cannot imply that FSR tested each candidate. Firsthand results from one product do not transfer to another, and a higher research tier does not automatically confer a higher ranking.
Recommendations should explain who a product may suit, who may need another option, what needs a small trial and when waiting or seeking better information is the useful next step. A shortlist need not be ranked. We do not use star ratings or universal product scores. Affiliate availability, commission or sponsorship does not determine independent recommendation order.
Editorial review and AI assistance
Research, independent human checking and publication approval are distinct responsibilities. Required checks must be represented according to their actual completion status. If independent human checking is unfinished, or no independent human checker is assigned, that status remains pending; it must not be presented as completed.
Labels such as “Tested”, “Hands-on”, “Verified” or “Benchmark” require relevant scoped evidence and the required human rechecks. A pending check cannot be converted into a completed review by an AI model or agent. A research tier itself is not publication approval.
AI may assist source discovery, research organisation, calculations, drafting and checking. Generated descriptions, simulated results and summaries of other people’s tests do not establish FSR product use. Outputs from an AI product being evaluated can be observed results when the actual task, inputs and conditions are recorded. FSR remains responsible for published work.
Funding, access and editorial independence
FSR welcomes affiliate partnerships and clearly identified sponsored articles, explainers, paid placements and collaborations. Funding can support or commission a topic, production or disclosed placement. Readers must be able to identify the relationship and relevant sponsor participation.
Sponsored material remains commercial content when it includes documented product use. Its factual claims still require support, and any testing must be described within the scope of the work actually performed.
Payment, affiliate compensation and supplied access cannot purchase a favorable independent conclusion, a research tier, an independent ranking position or the removal of substantiated criticism from independent editorial coverage. Conclusions can change when new evidence or substantiated corrections change the assessment. For commercial labels, sponsor participation and approval of commissioned copy, see Disclosure.
Supplied accounts, trials, credits and test environments can enable useful research. Material assistance and restrictions that affect findings must be disclosed. Access does not guarantee coverage or a favorable assessment; the tier follows the work actually performed.
Dates, updates and corrections
Publication date, article-update date and evidence-check date answer different questions. A layout or wording edit does not refresh the underlying evidence. Prices, features, availability and terms can change after a check; read the dates and scope alongside current vendor information.
When a material update or correction is made, our standard is to explain what changed and whether it affects the conclusion. This is not a promise of continuous monitoring, a fixed update interval or a guaranteed response time.
Readers and vendors can send the article URL, specific passage and supporting evidence through Contact. A dated official source, reproducible description of a problem or redacted screenshot may help. Include the relevant plan, region and date where possible. A report can prompt investigation; a change depends on what the evidence establishes.
Read About FSR for the publication’s purpose and editorial attribution, and Disclosure for commercial relationships.