IMHO, if you could only do one thing before handing off your project (either directly or indirectly), I would recommend that you double and tripple check that it compiles as-is from source control.
No laughing, but I cannot tell you how many times I've gotten "latest" from a source control and it failed to compile, only to find out later that I wasn't "on Fred's old box" because apparently the code "only compiles on Fred's old box". I even had a former employer promptly remove my desktop from my cube, and replace it with "Fred's old box" so I could work on the project I was suppose to.
As an extension of the above recommendation, because sometimes getting latest isn't all that is necessary to compile an application, I recommend that you create a README.txt and place it in the root directory of your application and put that in source control. This README document should contain a list of external dependencies that could not be checked into source control (if any exist), how to setup the database, and any other oddities about the compilation, execution or deployment cycles of the application.
Anything above and beyond the above two suggestions would just be gravy, but IMHO the above two are almost required on any project larger than "Hello World".
EDIT:
On the topic of documentation...
Over the years I've both written and read my fair share of software documentation for the purpose of easing a developer's transition. I'd say that such documents are rarely worth the paper they are printed on. Developers (myself included) rarely think of the important parts of the application while writing such documents, we only tend to think about the most recent fires we've battled. Above and beyond the fact that these documents tend to not cover all the important aspects of the software, they also get outdated VERY quickly. Once the document is out of date a future developer is more than likely going to completely disregard it instead of bringing it back up to match reality (think changing requirements).
Instead of documentation per se, I recommend unit tests. I know it probably sounds old at this point, but let the code do the documenting for you. Broken unit tests are hard to ignore (and easier to spot) than a Word document. Additionally, the English language is horribly imprecise for articulating the finner points of software design. There are simply too many ways to interpret the meaning of even the simplest of English sentences, and this just leads to confusion and/or bugs.
