I would always vote for hand-coding automated test over the use of Record and Playback. With programming test-cases its much easier to keep the tests DRY and if you think about maintainability of the tests up-front this will safe you a lot of time in the end. Some record and playback tools do support cutting up recordings in pieces and or replacing frequently used parts. But its hard (or maybe even impossible) to implement a Selenium best practise like the Page Object Model with a recording tool like Selenium IDE or Selenium Builder. Overal test recordings are harder to maintain.
Unless you have a very small set of test-cases and very limited time avoid using a Record and Playback tool like Selenium IDE. (This is true for any Record and Playback testing tool, not just web-based or Selenium testing)
Still these tools have some value and can be handy sometimes:
- Get started quick with a new test
See how the test recorder finds the control elements
This might be needed for example when you automate an menu and it disappears before you can use an element inspector on them and you don't have access to the code, because this element is part of a commercial library.
If you already started creating a lot of test-cases in the IDE, no worries. The IDE has an export feature under the file menu, which exports the steps to C# code and already wrapped in NUnit test methods. You should be able to refactor this to the Page Object Model and be on the right track in no time.