I try to think of the following advice as a must (like common sense, gotta have it -- i hope it's coherent enough).

If you're providing any kind of services dealing with sensitive information, do not hesitate to use SSL (accept nothing less , even if the underlying network is using IPSec, like it should).

Also, guard sensitive data with your life (do a search here on perlmonks about ideas for securing credit card data, i'll find a link and put it here)

Also, backup!
as in have a few backup machines (a replicated database server, as well as a backup app server -- some kind of load balancing is best)
as well as make lots of backups (got data? back it up! do it often! keep it secure!).

Set it up now, fine tune it, so in the future, when the company blows up, all you have to do is buy a few more machines, configure them, and all is well.

I listened to some yahoo dude give a presentation on DBIx::DWIW, and one of the features of the module is if a database server goes down (unreachable for an x period of time), the application automagically switches a backup database server (well if you provide one of course ).

In this particular case, the database of choice was mysql, with replication set up, so after one database goes down, another was made a master (there can be only one, it's the only db you write to), and the other backups kept replicating off of it. All session data was being saved in the database, so the user might notice an error message saying reload, after which at most he might need to re-imput at most a single page of data (if he's filling out a form for example, thus saving the user grief, cool ey ;)

That is gooood strategy
• detect failures (machine gone down)
• switch to backup
• notify admin
• do not blow up, never blow up (sounds good, endusers like it)

have a very happy holiday season (i'm tired)

MJD says you can't just make shit up and expect the computer to know what you mean, retardo! ** The Third rule of perl club is a statement of fact: pod is sexy.