I don't think you can sucessfully legislate code quality with a set of rules (especially not "must be OO", or "must be well documented"). Rules like that lead to OO solutions to non-OO problems, and documentation not worth the bits it is printed on.

Instead ask for code samples from the small company up front. And as YOUR code arrives, look at it. If you have time, perhaps you can write some of the source code comments or test cases, based only on the code you receive.

A second set of eyes is often the best path to clarity. The original author of the code is often too intimate with it to understand what the subsequent maintainers might find confusing.

I've maintained a lot of code. Far too often what the original author documented was already obvious to me based on the code. Usually I needed higher level hints -- like what the overall purpose of a code section is for. Or a description of the reason for a methodology or algorithm.