The arithmetic that decides it
A small team does not have a pilot budget or someone whose job is to evaluate tools. So the decision has to be arithmetic, not enthusiasm.
Take the task. Measure how long it takes today, honestly, over a normal week rather than a bad one. Then run it with the tool for a week and measure two numbers, not one: the time to produce, and the time to check and fix. The second number is the one that decides. A tool that halves production and triples checking has cost you time while feeling modern.
Against that, put the full running cost: the subscription, multiplied by the seats that will actually need it, plus the hours someone spends learning it and keeping it working. A tool that saves two hours a month and costs a seat per person across a team of eight is not a saving.
Where small teams do win
The pattern that holds up is narrow and repetitive work with a cheap failure mode. Turning a week of messy notes into a structured document. Drafting the fifth version of a standard reply that a human then edits. Extracting fields from documents that arrive in a predictable shape, with a human reading the result before it matters. First-pass triage of an inbox, where being wrong means a message is read a bit later rather than never.
Where it goes wrong
It goes wrong where the output touches money or a legal commitment without a person in between, where the input arrives in a shape nobody controls, and where the tool becomes a dependency that only one person in the company understands. That last one is the quiet risk in a small team: the automation survives exactly as long as the person who built it stays.