If you think about the controlling inputs to my tool: Primary is: Time (can be in # days), expected underlying price at end of that time (given as a +/- % from current), and expected volatility at end of that time (given as a +/- % from current Vol surface for that time reference). I merely compute the ending VS beginning value for all permutations of trade candidates, then arrange in ROR order. Intelligence is needed to produce the user selection for the price and volatility changes for your time in trade value! This evaluation currently requires the user to specify which Expiry their trade is to be in. The accuracy of the results is a direct function of the accuracy of the inputs provided (no magic here). I'm currently obtaining my data from my SQL database, which is 60-second resolution. For this exercise the real time data originated via TDA-API (note the database name reference).
The general idea is that if you have a good call on the price of the underlying security, volatility is only important when thinking about the break-evens.
First thing I was taught when volatility comes into the equation. If you are correct about trend and time, but wrong about volatility your trade will underperform. If you're incorrect about trend and time, but correct about volatility your trade will outperform. One of the biggest concerns we see on the site is the underlying did what I expected and the option lost money - generally, you made a poor volatility call. Every option trade has embedded in it an assumption about the trend or lack thereof - time and volatility.