Begin with the claimed boundary
When a product says local-first or offline-first, identify the core task and test it without a network connection. Read the privacy explanation and inspect whether an account, upload, or external service is required. A useful review separates the core behavior from optional network-dependent features.
Use representative inputs
Test a small clean file, a realistic file, a large file, and an unsupported file. For document tools, inspect text, page order, orientation, and exports. For analysis tools, compare output against a known sample and record parameters. A review becomes more useful when it describes the inputs rather than only the interface.
Look at failure states
A utility should explain an error and offer a recovery path. Empty selections, malformed data, denied permissions, interrupted operations, and storage failures reveal whether the product was designed beyond the happy path. A spinner that never resolves is a finding, not a minor inconvenience.
Check documentation and support
Look for a clear guide, privacy notice, version information, and a working support route. Documentation is part of the product because it tells users what the tool assumes and what it cannot guarantee. A review should distinguish missing documentation from a missing feature.
Write a bounded conclusion
Summarize what worked, what was not tested, and which users may benefit. Avoid claims that exceed the evidence. A trustworthy review is useful because it is specific: it connects a recommendation to observed behavior, representative inputs, and stated limitations.