Research desk
MethodReview methodology
Scores only when we actually use the product—on real tasks, with named limitations.
Hands-on reviews exist to answer a practical question: is this product worth a buyer’s time and money for a defined job?
When we test
We test products that are publicly available (or provided with standard trial access) and relevant to our audience. Access provided by a vendor is disclosed and does not purchase the outcome.
Test design
- 01Define the audience and core jobs to be done
- 02List at least three concrete tasks before testing
- 03Note setup friction, reliability, and output quality
- 04Check pricing, export options, and key limitations
- 05Record test duration and date
Score model (100 points)
- Practical value25
- Product quality20
- Ease of use15
- Pricing value15
- Differentiation10
- Transparency10
- Support & docs5
Breakdowns always sum to 100. Scores are not normalized against competitors on a curve; they reflect the product against the stated jobs.
What scores are not
A score is not a stock rating, a security audit, or a guarantee of future quality. Products change; we recheck when capacity allows and when readers flag material changes.
Limitations we always look for
Every serious profile should name a primary limitation. Marketing pages rarely do—this is intentional.