I thought that was very strange as well. I suppose it's as far as one can go with title inflation: "Code shop looking for rock star code monkeys/CTOs to work for equity."
Indeed. If he is hiring for a CTO, why has he made the technical decisions up front? I realise he has had a MVP built in Ruby, but that shouldn't dictate the technical platform - leave that for the future CTO to decide.
I made them so I could get something built quickly, and the development team I clicked with happened to build Ruby applications. I'd certainly be open to a change once I hire a CTO. I honestly don't know how hard it is to switch from one platform to the next, I assumed "very" so I looked for Ruby devs only. Maybe a bad assumption?
Oh, I'm with you on the "get a prototype up and running, using consultants" part. Definetely a good investment. But depending on how much work was poured into this, it's probably relatively trivial to re-implement. It is a minimally viable product after all, I hope?
There are three reasons why I would suggest that you don't emphasise the proficiency in Ruby. The first is, as mentioned above, that you're probably overestimating the effort required to switch platform at this point. The second is that a good programmer who just happens to have no/limited experience with Ruby will probably be able to adapt pretty fast, provided he has experience with similar technologies. By limiting your search to those that already know Ruby well, you're avoiding a lot of potential.
But the main reason why I think it's a bad idea, is because you are making decisions that I believe is the domain of a CTO to make. By doing so, you are sending a signal that you don't respect/trust him to make that decision. That is going to make the type of person you'd want onboard think twice about joining. I'm not suggesting that you actually feel this way (I don't know you, so I couldn't pass that judgement), but you should be aware of the way it will read to - at least some - people in your target demography.