One does not normally start off a project with technical requirements, but I'm replacing an existing system, so...
TestingIt almost goes without saying, but this will be a BDD project. I will use Cucumber and Rspec to perform outside-in development.
I have decent experience with RSpec, having used it in my day job and for converting EEE Cooks to Rails in the first place. I also have some experience with Cucumber's predecessor, Story Runner. That said, my BDD has tended to lapse on me, so committing to it from the outset here will improve that skillset.
The Data StoreThe choice of CouchDB for a backend to EEE Cooks is not completely crazy.
In its initial incarnation, EEE Cooks had a document-based store—an XML based store to be specific. Both the meals and the recipes that comprised the site were written in a custom XML format. We then baked the documents into HTML using XSL and make before publishing them to the production site.
The transition to Ruby on Rails was not a trivial one. The documents needed to be mapped into a relational database store, which did not always prove easy or natural. Moving back to a document store should ease some of the awkwardness of the relational DB.
The natural fit of a document based store is not the primary reason that I choose to use CouchDB. Mostly, I just think it's cool and I want an excuse to play with it.
Other ConsiderationsIn addition to the backend, we have always had a full text search index. In the original XML-based system, we used Lucene. In the current Rails version, we use acts_as_ferret (a ruby implementation of Lucene).
The RestAside from the choice of CouchDB and the need for a full text index, I am making no other technical decisions at this point.
Next up, source code management.