What I’m building is not meant to be a replacement for all web upkeep tools – it’s not meant to serve the myriad of purposes/needs that so many tools provide. But I agree – in some contexts, more robust and complicated tools are absolutely essential.

The need/opportunity I see is for small-medium scale sites, which are often over-served by some of the larger tools.

In terms of desktop software like iWeb, it seems to me that most of them produce crap code, to greater or lesser degree. But really this points me to the lack of definition in my description of whom I imagine could use this tool I’m building. My thought is that this would be used by web agencies who need to develop highly custom-designed websites for clients with a limited number of non-technical folks tasked with updating the site. For these clients, cracking open a desktop tool is too much to ask, regardless of the quality of output.

Regarding your example of asset management: this is very good food for thought. I do agree that re-inventing the wheel is a waste of time, but in some cases lessons learned from the UI approaches of newer tools could inform and improve user experience and workflow.

I don’t expect to get it all perfect the first time. I do expect that there will be many features/aspects that I’ll need to trim for time and want to add later (maybe robust asset management!)

Regardless, I’m finding application development a fun road to travel down. Thanks very much for your input.

First, let’s not discount software like iWeb, RapidWeaver, or Sandvox, desktop drag-and-drop Mac applications designed to quickly and easily build small sites.

You apparently want something bigger. Take something as simple as asset management. You’d think that it’s as easy as uploading a few files to a directory. But no, uploading isn’t really the issue, as in a usable system you actually have to be able to FIND them again. So you’ve got titles and descriptions and tags and categories (which themselves need to be managed, selected, and edited).

Then there are thumbnails to be generated, as images need to be seen to be picked. (Add media pickers to the list.) And THEN there are scalability issues. Uploading to a single server? To an image server? Can you handle 100 images? A thousand? Ten thousand? A light news site or blog may need 5-10 new images a day, which could be 3,650 a year.

And that’s just one little-bitty slice of such a project. Just food for thought.