How we test
Software is easy to recommend when you’re only looking at a feature list. We try not to do that.
When we cover a product, we want to know what happens after the signup screen: how long it takes to get useful, what still needs manual work, what breaks, what it connects to, and whether the setup still makes sense once the novelty wears off.
Hands-on tested
When an article is marked Hands-on tested, we used the product ourselves. That can include setting up an account, building a real workflow, connecting other tools, testing common tasks, and seeing what happens when the setup stops behaving the way we expected.
Research verified
We can’t personally use every product we cover. When something is marked Research verified, we haven’t tested it deeply enough to claim first-hand experience. We check official documentation, pricing, changelogs, integration docs, support pages and credible outside sources instead.
We’d rather say we haven’t tested something than write as though we have.
What we care about
We don’t judge software by feature count alone. We care about whether it removes work, how much setup it creates, how hard it is to maintain, what else you need to pay for, how well it works with the rest of the stack, and who would probably be better off using something else.
Pricing
Software pricing changes. We check prices when we publish or update an article and show the date where pricing matters. If usage limits or extra credits change the real cost of a workflow, we try to include that too.
Affiliate links
Some links on HITORI STACK may be affiliate links. If you buy something through one of those links, we may receive a commission. That doesn’t determine whether we include a product or whether we point out its problems.
Corrections
Software changes. So do our conclusions. When something becomes outdated, we update it rather than pretending the original version is timeless.
Last updated: September 2026