On Drupal.org there is a discussion about how various web designer/developers would approach developing a simple website with just a few static pages.

The pejorative term for this kind of website is "brochureware" ... and in this case it is rather descriptive. Most websites -- especially small business sites -- follow this holdover of 1990s worldwide web thinking, where the website in question effectively serves as an online brochure.

The exercise on Drupal.org turned out to be interesting, at least to me, so I thought I'd repost what I wrote there:

The idea of having a CMS to do a brochure site is that the client can change the content easily. Even a simple brochure site goes through periodic updates, and not just from press releases. Prices change, contact info changes, who's in the company changes, and so all of these changes can happen much more easily than with strictly html. That is why I think it's worth the extra work maintaining the code security, etc. [This first part was in response to previously made comments.]

1. The Pages
• An About Page -- This would be created using page node type. I would remove the author info from node-page.tpl.php and put a time stamp visible in full body only, to note the update date. Some people fear placing a date on content, but I think it's important to know how fresh the info is. The client would have to be reminded to manually update the date on the node when she/he edits the node, and I would recommend making versions.
• A Contact Us Form -- I would use webform for this, and create a custom form that allows for business-specific queries.
• A Products (or services page) -- This would be created using page node type. If there are offerings in subcategories, I would consider using outline to create books, or using the book module itself. Alternately, one could use taxonomy to create the structures. If it's a visually appealing array of items, I'd also urge an image gallery, and set up the image assistant to link to the image nodes. This can prove helpful in other content types.
• A simple front page with two paragraphs about your company and contact information -- This would be a page node type, and the only node "promoted" and "sticky" (why, explained below).
• plus a sidebar with links on the right or left which link to headlines from your five latest news articles -- This would be a custom php snippet in a block.
• A news page with news articles about press releases, events and news -- This would actually be a story node type with php snippets to show the most recent relevant items, drawn by taxonomy. The individual items -- events, press releases -- would be flagged by taxonomy, and accessible from links on this anchored page.
2. The Modules
• Image and Image Assist -- These would be used for products and for staff portraits. The nodes themselves would have detailed descriptions/bios, while the pages into which the images are inserted can have more general info. This makes for easy updates of this kind of content. Image assist would be configured to link to the relevant image node. node-image.tpl.php would be customized as node-page and node-flexinode-x to show just the date.
• Flexinode -- For events, and for press releases. The flexinode for press releases would be pre-formatted with the "For Immediate Release" etc. Press releases will have their own tag, and the RSS feed for that taxonomy will be linked on the front page. The module also would be used for events, obviously. Both would share a taxonomy that puts them into the news page php snippet.
• Taxonomy theme -- This would enable each page to have its own unique and complementary look. Before this module was available, I used custom theming on different node types, but this module would allow for entire color shifts.
• Taxonomy image -- Sometimes it can be very helpful to have a nice graphic show up in association with a topic. A product line could have its logo on all its pages, for example.
• Pathauto -- I would use the regular path to define the anchored pages, but the press releases and events would benefit from automatic descriptive addresses.
• Simplenews -- Because email lists are still the popular way for a lot of people to keep up with your site and business. This would have a block on the front page.
• Nodewords -- Keyword metatags are losing significance, but they're not irrelevant yet.
• TinyMCE -- Depending upon the client's comfort with html, I would consider adding a wysiwyg text editor.
• Glossary -- If there's a lot of jargon on the site, the glossary module could be very useful to have on-site background info without cluttering the site with footnotes or TMI for knowledgeable visitors.
3. The Architecture
• Main navigation -- I would put this in the header, saving the sidebar (using only one, most likely) for the dynamically updated info.
• Nodes -- I would leave the default node.tpl.php alone, and use customized node templates for the content, leaving the most flexibility down the line for expansion.
• Blogs -- Even if blogging is not in the cards in the short term, I always urge clients to consider business blogging as a way of offering more personalized publicity and a better sense of who's in this company and what they're about. Blogs could be added simply by enabling permissions and adding a link in the navigation, with a complementary theme to be added.
• Promotion -- It's amazing what a dynamic front page can do for SEO. I would encourage the client to consider promoting the news-flagged nodes to the front page (and thus falling under the sticky), with say 3-4 nodes displayed per page. Teasers would be short. But front-page changes with new content is valued by search engines, so if net-based promotion is important, I would urge this.
• Strategy -- Many people who want a brochure site don't really grok what (I hate to use this term, but in absence of a better alternative for now...) "Web 2.0" sites can do for them. So part of building the site is educating them on what they can do in the future. A client that gets more out of their website than they expected is a happy client, and that's a good thing.

Overall there would be about 5 themes to create, to give each page its own look (via taxonomy theme). This way the site can expand without requiring rebuilding from the ground up.

This is an interesting exercise. I welcome comments on these ideas.