As hubb0r points out, the make steps will ensure that everything happens correctly. Mostly. For example, if there is any native (XS) code, it'll get compiled into appropriate libraries, etc.

That said, I've found two things that are key to making my life easier with non-standard install paths (aka private install paths): PREFIX and LIB, e.g., "perl Makefile.PL PREFIX=/srv/www/lib LIB=/srv/www/lib". I set them both to the same place, and then use lib "PREFIX/LIB setting" in my code, and everything is hunky-dory.

The advantages really are two-fold: one, if there is any XS code, you can be sure you're compiling correctly (if this fails, then you have some serious advanced issues to deal with - such as compiling on a machine other than the one you deploy on, which is something to be sure you know how to do before attempting it), and two, you can run the tests in the real production environment which helps ensure that your code will work, too - if you get errors during the make test phase, for example, you may be a little suspicious as to whether you have everything needed for that module to work. Or just running "perl Makefile.PL" - if that fails, it should tell you what other modules you're missing. I've found modules where "perl Makefile.PL" failed to tell me about a missing requirement, but running "make test" failed due to that missing requirement, then I went and installed that extra module, and all worked after that.

You can really save yourself a lot of hair pulling by doing things the "normal" way. If you don't, you need to be aware of the errors that you may encounter and what they mean - they aren't nearly as obvious later in production as they are during module deployment.