How we test and research

Most review sites tell you they test everything. We don't, because it wouldn't be true — and a methodology page that overstates what we do would defeat its own purpose. Here's the actual process, including its limits.

Three levels of evidence, labelled on every article

Not every product can be evaluated the same way. A browser-based tool can be opened and used in minutes; a piece of Windows-only desktop software, a graphics card feature, or a $70 game cannot be, at least not by us right now. So each review states which of these it rests on, usually in a note at the end:

1. Hands-on tested

We opened the product, used it, and are describing what we actually saw. This is the standard for anything that runs in a browser or that we can access directly — web apps, free tiers, trial accounts, publicly reachable interfaces. When a review says we tested something, it means someone put it through the steps described, not that we read a spec sheet carefully.

Example: in our review of free creative software, the Photopea section is based on opening the editor, creating a document, and working through its interface — including noticing how much screen space its ads take up, which is the kind of detail that only shows up in use.

2. Documented research

Where hands-on testing isn't possible, we build the review from primary sources instead of guessing: official documentation, published pricing and policy pages, terms of service, independent testing labs, and reproducible technical explanations. We say so plainly, and we name what the claim rests on.

Example: our antivirus comparison uses scores published by AV-TEST and AV-Comparatives — two established independent testing labs — rather than pretending we ran malware samples ourselves.

3. Aggregated reception

For things like games, where a single opinion is less useful than the weight of many, we summarise what critics and players reported, cite the sample, and include the dissenting view rather than only the flattering one. We don't present an aggregate as though it were our own playthrough.

What we will not do

• Claim to have tested something we haven't. If a review doesn't say we used it, assume we didn't, and the article will tell you what it's based on instead.
• Recommend something purely because it pays well. Several articles on this site conclude that the free or built-in option is the right answer and that you should not spend money — including cases where a paid recommendation would have earned a commission.
• Hide the drawbacks. Every recommendation names who it isn't for. A review with no downsides is a press release.
• Publish stale figures without flagging them. Pricing, free-tier limits, and platform policies change constantly. Each article carries the date it was last updated, and where a figure is volatile we say so and tell you to check the source.

How these articles are written

Our articles are researched and drafted with AI assistance, and every one is reviewed, fact-checked, and approved by a human before it is published. We think you should know that, for the same reason we label our evidence: you can weigh what you're reading properly only if you know how it was made.

What that means in practice is that the process above isn't decoration. Claims get traced to a primary source, figures get checked against the company's own current documentation, and anything that can't be verified either gets cut or gets labelled as unverified. Where we couldn't test something, that limitation is stated in the article rather than papered over.

Affiliate links

Some links on this site earn us a commission if you buy through them, at no extra cost to you. That relationship never determines a verdict, and it never buys a position in a ranking — full details are on our disclosure page.

Corrections

If something here is wrong, out of date, or unfair, we want to fix it rather than defend it. Prices change, policies get rewritten, and products improve after a critical review. Corrections are made to the article itself and the updated date is changed, so you can see the page has moved.

This page describes our process as of September 2026. If our methods change — for example if we gain the ability to test hardware directly — we'll update this page rather than quietly change the standard.