If you are like 99.9%+ of people who try their hand at game development (and I am one too), your #1 biggest challenge is getting something playable, followed by #2 getting something other people enjoy playing too.
The problem with simultaneous platform development is that you are putting both of these milestones farther off, in exchange for largely illusory gains; the illusion being that having so many balls up in the air will make the total project time less. If it does its only because something got dropped, and possibly the whole project was scrapped.
Planning for multiple platforms is fine, however. You need to have this in mind when you are picking technologies, as imagine making a game 4 years ago in Flash with a goal being deploying it to iPhones; that would have required a lot more work than starting with a different platform, or cutting it and making it a wish list item for the sequel.
As to what methodology, I would recommend a version of your #2, but with the front-end first. The front-end is the game to the player, and that's what matters. A flawless back-end with a bad front-end is not really a game at all.
So I would suggest picking the platforms you know you want to target (browser [Firefox, IE 7+ only, and Chrome?]), iOS [version 5+?], Android [4+ only?]), Ruby web server as a back-end tech sounds just fine. Make sure what you want to do is seemingly doable on your target platforms; now a days it probably is, but if you are thinking anything tricky with 3D it gets a bit more dodgy.
Knowing your target platforms allows you to intelligently pick engines, design tools, etc.
Then I suggest picking the platform you feel like you'd be most comfortable in for maximum development speed. Prototype a feature on the front-end (the game), probably by faking the server call with a dummy, and when you are happy with the feature and how it works/plays then implement the real thing on the backend.
This way you isolate the source of errors, and you might find that a feature you thought was a good idea doesn't make sense at all when you playtest, allowing you to cut the feature completely and skip having to implement it on the backend at all.
If your chosen technology makes it easy to compile over to a different platform, then at various milestones you might want to give it a test drive on a mobile device and see how it's going. It won't be perfect, but it helps to keep you from designing the whole thing with platform-specific features that flat out won't work on other platforms. I practice this with web development and browser versions, and it keeps endless platform testing to minimum while keeping me realistic about how big of a deal its going to be to support platform X.
You might want to support Android 2.2, for instance, then find out its going to be a huge time sink for some reason and decided to just drop support and save yourself the headache; or maybe its works great and iOS is making you wonder if it is worth it at all, etc.
Once you have a version you are proud of and people like to play in the browser, you can then know approximately how big of a deal mobile versions will be, and whether or not you even want to bother. You will be more likely to finish, less swamped with minutiae (how iOS vs Android handles screen refresh is NOT important to having a successful game on the browser), and probably find the whole experience more enjoyable and less overwhelming.