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.

The only thing I can imagine that I'll need to be storing, at least for the present applications I'm envisioning, would be session information. Also, there are maybe 10 people total who would use these, with a maximum of 5 at once, typically. I'm actually thinking files or dbm would be good enough for my persistent storage needs.

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...

I like the advice I received from Corion in 198061 above that I shouldn't modularize too early because it creates testing headaches. I also think he's correct in saying that I'll be throwing a lot away. This is especially appealing because I will be working alone and I'll only have user testing to give me direction.

Ahh, many paths to mastery...

Thanks for the good advice, though. I like your point about documenting and planning. Yes, I hate the feeling of relearning your code and coming up with future enhancements that you've already considered and forgot.