Congratulations!
Only “a bit”, so I suggest not even thinking about the “easy” aspect. As I tried to make the argument in that blog post, use processes if they bring some runtime benefits.
This is a great analysis, and I believe the conclusion would be to use multiple processes 
Clearly they will bring many tangible benefits. In the case where you had to deal with a larger number of sites, you might even want to consider having an extra pool, which would limit the amount of sites you’re checking at the same time. So you might end up with N + M processes, N being the number of sites, and M the size of the pool (probably much smaller than N). And of course, a few supervisor processes would be needed as well.
So in the post, I wasn’t advising to be conservative with processes. I usually say in my talks that larger systems will easily reach for hundreds of thousands, maybe even millions of processes. There are many benefits which you gain if you split the total work over a large number of processes. So if you see potential for concurrency, definitely go for it.
However, using processes to simulate objects, and separate logical concerns in a sequential problem, will not get you anywhere. It will bring some problems, but you’ll get no benefits of processes.
I also recently posted a bit about this topic here.
