1. Use ActiveResource and avoid ActiveWebService. With ActiveResource and multiview support in Rails 2.x you can easily expose RESTful models as well as Atom/RSS feeds on these models as well as JSON and any other view format you can wish for.
2. Consuming ActiveResource is easy by using self.site = "URL" in the client side. However, that does not add data to the DB and every query will result in a REST call. Caching data is key.
3. Use Rake to automate any other tasks you do. Custom Rake tasks are easily added in lib/tasks. Use $rake -T to see current tasks available, including yours.
4. Use database migrations to update models once your design is solid and you have a first release and cannot avoid data losses. That is, to be clear, use one migration per model early on and then once app is released for beta, every change to the models should be via new migration (not an update to the old migration). This will save lots of headaches in future and allow you to easily move application from one version to next one.
5. Use Solr vs. Ferret for models searchability and associated acts_as_xyz plugins. This is due to the fact that Ferret indexes tend to get corrupted. This, in some sense, is a shame since Ferret is a nice and easy plugin.
6. Make sure to use Rails validations in your models. I would avoid special DB statements in migration code. This makes it easier to move to different DB, e.g., MySQL to DB2.
7. Use view partials to keep your views DRY. Essentially, partials should be any view code that is repeated, similar to a subroutine call (PullUp or PushDown method refactoring). Use a app/views/shared directory for partials that are across controllers. Also, always use the controller (or shared) name when calling the partial.