Articles are being implemented before ratings because my domain model of ratings is that they are “created by users, about articles” – so having an article to rate (or review) needed to be implemented before I could implement the rating or reviewing.

An only registered users can create articles, so Users has been implemented before / concurrently with articles. We need to have some users logged into the system and submitting articles in order for the rest of the users to be able to browse them.

I think the very first prototype may only have the “our niche” top level area – I really want to get it out tomorrow (Saturday at the latest). I am leaning towards areas being pre-defined (like digg). In that case, it may make it into the first prototype.

you wrote about the sequence of things you develop: users, then articles, then ratings. Here’s my somewhat methodologic question, just because I’m curious:
Why do you start with users? And why do you put ratings after articles?
The prioritization of the use cases gives me “browse an area”, “suggest an article”, and “comment an article” as the winners. I don’t believe you really need users for these three. Also, the next thing after articles should be comments.
I understand you need articles with areas in order to browse them, so the second prio could be transformed in a function that is implemented first: suggest an article. Once you can suggest, you can prowse and and you can comment.
Please expand on this a bit. Cheers to your Ruby skills anyway!