You should regulate it like ANY OTHER software shoppe should.

number a. Keep anything that could change during the lifetime in the company in cvs. And anything that can be derived from it, out. Source code, html, gif's for the website, server configurations, yes. Compiled binaries, no, unless you have no source for them.

b. learn change control. I mean this two fold. 1. learn cvs and usage techniques, such as branching and tagging and when to use them. 2. Dependency management is a pain in the ass. Internals to modules chnage, and develoeprs aren't always the most vocal bunch to say, "I'm using ThisModule.pm version 1., 2 breaks my code." Sometimes they simply aren't aware.

I think you opened the wrong can of worms :) You see, you aren't asking about using perl per-se. You are asking about developing and maintaining a system. You may want to pick up a book on systems analysis and design, as well as software engineering. You don't have to use ALL the concepts in them. After all, you have limited cash and resources, and experience. Each company works in unique ways, but more importantly, you should look at examples and test ideas that other people use. CVS (cvs/perforce/subversion) and change control, qa... overly excellent ideas that no one should do w/o. How your software starts and finishes from an idea to comletion and maintenance, that is accomplished via growth.