Cost the whole thing rather than the price. The subscription, the hours to set it up, the time to learn it, the work to migrate existing data, and the ongoing attention it will require. A modest monthly fee attached to two days of setup and a recurring hour a week is a substantially larger commitment than the number on the pricing page, and that fuller figure is what should be compared against the benefit.
Then quantify the benefit honestly, in hours or in money, and be sceptical of your own estimate. Saving twenty minutes a week is about seventeen hours a year, which is real and is not the transformation the marketing describes. Errors prevented, work that becomes possible rather than merely faster, and things you can stop paying somebody else for are usually worth more than time saved, and they are easier to verify.
Ask what happens if it is wrong, because that determines how much diligence is proportionate. A tool you can leave in a month, whose data exports cleanly, and which nothing else depends on is a cheap experiment. One that becomes the system of record for customers or finances, with a migration cost, deserves considerably more scrutiny before adoption than after.
Run a real trial rather than a demonstration. Use it for the actual work, with actual data, for a defined period, and decide at the end rather than drifting into a subscription. Most trials are abandoned halfway and renewed anyway, which is how businesses accumulate tools nobody uses.
And set a review date at the moment you subscribe. Three months later, ask whether the thing you were going to stop doing actually stopped. That single question, asked once and answered honestly, is what separates a stack of tools that serves the business from one that accumulated.
Be particularly sceptical of anything replacing a process that works, however inelegantly. The cost of switching includes the errors introduced during the transition and the period where nobody is fluent, and those are real and rarely counted. A tool needs to be substantially better rather than marginally better to justify replacing something functional, and marginal improvements are where most software spending in small businesses actually goes.