Generally-speaking, an "expert" is not likely to be interested in periodic code review engagements:
1. Most "consultants" aren't working on an hourly basis, at least one free of reasonable minimums. In other words, good luck finding an expert-level developer eager to take on periodic hour-long "Is this code okay?" projects.
2. A real code review consists of more than just a cursory "this is good code, this is bad code" analysis.
3. A code review doesn't really help a client who doesn't have the ability to rectify issues that are discovered. I can guarantee you that a consultant asked to perform a code review in the scenario described here will nine times out of ten find himself being asked "How do I fix it?" Unless the client is prepared to pay for the skills of a quality developer, getting involved in a "How do I fix it?" discussion is going to be a tar baby for the consultant in question.
4. The author is generally distrustful ("Don’t trust reviews or portfolios", "the motivation of most freelancers directly competes with writing concise code") yet curiously he doesn't consider the possibility that the "expert" you bring on to review your code, if he's looking for development work, has an incentive to raise questions about the quality of the code.
Not all of the advice here is bad, but I think the author generally glosses over the fact that finding good freelance developers and doing so when you have limited technical skills and experience managing the development lifecycle is difficult and may not be a viable approach.