wow, what a post!

I've done something similar where I work. I've used CGI::Application and HTML::Template (as C::A provides hooks to it) for the application framework. I written some extra mechanics to handle sessions, logging administration etc etc.. Its all OO based, and all relatively abstracted.

This has really worked very well for me and the team that uses it. Its *very* easy to develop new applications, and plug them in, all with implicit session management, and access control. In fact its worked so well we've got a list of projects we're developing for other depts' in the company. Like you we're automating manual tasks, and building new systems... what you've mentioned is perfect for this.

One thing you havent mentioned is persistant storage, or state preservation - we use an RDBMS, Oracle specifically, however if you write SQL92 complient code, it doesnt really matter which engine you use.

Should I focus on developing a good working set of modules for the common operations and build from there?

If you're starting out cold, I would build a nice extensible framework, then once you have the framework in place, building the applications is easy.. :-) The way I work is to design the application, then think about abstracting pieces of it into a set of modules you can use later. Typically I use a two tier model. The top tier is the web interface, the bottom tier is the interface to the physical infrastructure (OS, Network, Database etc). I've found this to work pretty well.

What about application logging?

We have the framework logging access to the applications, and each application logging all the "important" things. Rule of thumb: Log enuff to provide an audit trail to provide accountability. Some may not agree with this, however if someone finds a bug in your code, you should be replicating it in a stage (or integration) environment, where you can add whatever level of debug code you like...

Platform?

Personally, i'd go for whatever you have two, or three of... 1 for production, one for integration to production, and one for devel. You have the advantage of a spare of your production one fails... If you need to ramp up, grab a layer 4 switch and put 2..n machines behind it. That type of design will scale right up.. :-) (assuming your backend can keep up).

Devel time and root?

Depends on how much support you get from admins. I've worked in places where the admins are fantastic and provide all the support you could ever want, and workd in places where you almost need to hack the box to get anything done..

Any advice on how to be productive ..

Plan, design and document. Put your thoughts down on paper, review, revise then code. I can tell you from experience, if you're designing and coding on the fly, you can end up in all sorts of unscalable and unmaintainable hell. If you need to cut and paste your code into another application - my rule is to abstract it out, define the appropriate class, and bung it into a module. There is nothing worse than having to come back and re-learn your old code... having pod to explain the interface, and inline comments on bits of logic is great. Also, a very handy bit of doco to have is why you *havent* done things. Many, many hours have been lost to rethinking solutions...

Hey, you've got a fun project here, and the time you spend upfront in designing and building a framework to house your applications will be time well spent, when you start churning out application after application after application ...