Selenium/Webdriver is a great tool, but it comes with some overhead you'll have to be prepared to manage. The first is choosing which Programming Language bindings you intend to use. Whatever that ends up being will be the standard for the project for a long time, and depending upon the level of person you hope to use to build it, it can impact your choices greatly.
Be thinking up front about maintenance costs, and try to build it with the same software engineering principles you'd expect in production software. That means if its Object Oriented, use a little design, and refactor it frequently to remove unnecessary framework duplication. Try to keep the locators for each page in distinct files/classes, and each class you add to the framework should have a singular clear purpose. When you see the opportunity to refactor, because a piece of something would be good elsewhere, do it then, don't wait to refactor.
The other thing to consider are back end issues like: How am I going to setup and maintain my Selenium Grid/Hub/Node Instances? How am I going to launch the tests (which may vary depending upon how you intend to run them, what continuous integration servers you may implement.) You also may want to think up front, do I intend to include behavioral driven development like Cucumber, JBehave, or Specflow (or something similar) at some point. If you are, i recommend trying to start small with the breadth of the framework up front, and try to build that in as early as possible. The longer you wait to do that, the more tests you may end up having to transition.
Remember to provide good robust clients, api wrappers, mechanisms for spinning up data, or generating test fixtures as you need them. Keep them simple, but make them easy to use. Be sure that you will also have the coding tools you need to do it effectively. (Using the SeleniumIDE and then copying the exports, is a good place to start learning, but at some point, the need for that tool should diminish). Provide quality IDEs, source control, and sufficient infrastructure to run the tests on, or the efforts will be wasted.
Oh, and if you can build adapters for the database, or the APIs for your website, then by all means, do so, wrap tests around them and any other class that's part of your framework (that is not itself a test), and run those tests regularly too. Use APIs to setup as much data as it permits, and avoid doing setup and teardown only in the UI. Furthermore, if you can spin up the environment, deploy, then run the tests, then you may not need to worry quite as much about cleanup. I say may, because there are still cases where cleanup for the next test makes sense.
Lastly, be prepared for maintenance. Be prepared to find tests that seem flakey, but are really asymptomatic of behavior that is not as synchronous as it once was. Try to keep tests as small as possible, but detailed enough to not bring down the house. Honestly, I'd be very focused with the UI tests, and have a clear strategy for what you intend to cover, and what you leave to lower level unit tests to hopefully find. (there may not be sufficient time to write selenium tests for every edge case you can think of).
I hope this helps.