I am just finishing up on a similar site, end users (and we are talking extreme non-techies) post documents to a site (about 130 docs so far) that has search capabilities.

The initial plan was to create a database to store everything about the site, including content (in fact the end users did this in Access and it got out of control, they cannot even maintain it...so IT has stepped in to resolve the mess). Turns out the site may be a throw away within a year, so I tossed the database idea (switching to Oracle was overkill, $$-wise, and no way was I going to entertain leaving it in ASP/Access), and came up with the following.... It sounds very similar to what you are working on....

Here in a nutshell how I implemented it (using only standard perl, and CGI.pm):

• end users build their own docs from well-commented templates
• all pertinent doc data is in META tags, stuff that help build a categorized (division, jobclass, keywords, among others). Users use a custom CGI that assists in uploading to the unix box (FTP is too complex)
• a perl job "compiles" the site index from these META tags, creating a base file that produces the index via CGI. this index file is essentially a CSV, with the keywords in a column derived from the META tag keyword=
• I use a simple grep from the search widget to create a categorized doc listing of the subset of found documents
• created some simple tools to create the minimum required set of META tags, they just paste them into the doc. as well as an on-demand index generator and some other self-serve tools to maintain the site.

The end users got their first test drive last thursday and it did just what they needed without being overly complex.

Anyway, this method worked well for us, and went from concept to reality in just a few weeks, despite being a "side project".

...not sure something like could work for you, but since you seem to be solving the same problem...and of course TIMTOWTDI!

have fun!