TL;DR option, which is normally at the end.
- Foundation CSS framework,
- Recent jQuery, injected es5-shim to support older browsers;
- Standard install for Symfony 2.5, Doctrine2/ MySQL, twig etc;
- PHP 5.6 to test, PHP 5.3.12 on live;
- phpunit etc as standard;
- Designed/architected a templating and content storage structure;
- Didn't BDD/ Behat due to timescales, and good level of certainty on requirements. 
- Organised web fonts, but didn't use them (the design used Georgia, which is default on Apple and Microsoft products). See why I present this as an option to clients.
A publishing company called Seven are contracted to Sainsburys to administer a brochureware mini-site advertising products for Sainsburys collections under the brand personality of Gok Wan. Seven need to release a new site every two months with the current range the Gok Wan clothes.
There was a standard brochureware toolkit that Seven where using, but this wasn't customised to that template on the brochureware, and was abit inflexible. The Seven Digital are a Symfony2 shop. Seven would like to make this process more efficient, so hired me to build them a narrow purpose CMS. The CMS was for internal use, had no scalability requirements (although obviously the result sites must be scalable), or internationalisation. The availability of the CMS as a service was very critical for about a week per a month when it was being used. Administration could easily be performed the other three weeks. Due to the constrained audience, being fast to solve problems was more important than being simple for casual users (They already had to do detail on the existing standard tools, and where in the publishing trade.). Due to the nature of design, undo and revertability are important considerations. The published websites need security, although this is quite simple, as there was little data submitted from users. The CMS was entirely internal, and held good practice, but no effort for security.
This article is quite long. As standard commercial practice, I left the plans and notes at the company; its their property and they may wish to extend the work later.
The mini-sites that the CMS creates where expected to be four pages each. To make things fast to edit, each page is composed of blocks (this is quite standard for this style system). The settings on each block may be set, and the content. Each block includes instructions to make it responsive etc. With a standardised variable naming scheme, blocks types may be swapped; with comparatively little effort. It was expected the designers/ users would like to make small cosmetic changes to the blocks (e.g. center the text here). We called these 'tweaks' in the design meeting. These would be created as JS or CSS, and injected into the page header. An eventual goal would be to allow the creation of new blocks via saving a block with a stack of tweaks as a new thing. This will lead to messy code, but allow a good level of design responsiveness.
With discussion with the tool users, it was decided that the editions should be named (in the URLs) via a name, rather than a date or edition number. The CMS as tool will simplify the name space of later editions of the mini-sites. It allows editions to be published and unpublished as clean atomic operations. The previous editions had been published to URLs on an adhoc basis.
Each block will either contain images, text or both. Obviously both of these must be set on a per use basis. Each block has attributes (e.g. text could be red or black), which defined in advance, and may additionally be set. The reason for defining these in advance, is for generation of UX so the user doesn't need to be fully fluent with CSS and JS. For a content editor, basic knowledge is assumed, and likely to be acquired if absent.
The earlier guess of a week to create the mini-sites is against delays for the images, the URLs, text from the client etc; then to iterate as people refined their views.
Due to the constrained time scales, I attempted to use a wide variety of imported technology. This is quite standard, and indeed the reason for using frameworks. As front-end libraries need a multiple times more testing (each webrowser); I used libraries which have been tested to a known standard where possible. Seven digital prefers the Foundation CSS framework where possible (rather than Bootstrap 3, which I previously used). As a flexible professional, I adopted the local standards. The portions of the platform that require user-input used the widely adopted and understood jQuery and jQuery-ui.
Seven Digital use a more complex version of HTML5 than my default template. I adopted their values, although I'm not sure this will do anything in real terms. I do note that the more advanced features aren't compiled into tidy 1 yet, so pages now break validation. Everything is according to the HTML5 spec 2, and the webrowsers report no problems.
Obviously I made best possible use of Symfony features. I added a wide range input validation rules, for the custom text input.
I find it faster to create the database as straight SQL, the pull this out via Doctrine; then create the Entities. In other places, I was sharing data design, so used diagramming tools (which export to SQL); but didn't need to here. A linear typing stream, when there are no secondary teamwork requirements, is faster. As this was a single objective without many releases, I used GIT as a deployment tool (after manually making the Apache config). I guess there would be more reuse if I put the config in the repo; but previous experience generally left the service settings in the control of some sort of devops or net-admin.
Editing of photos is an obvious extra feature, but omitted from the specs. This is a business analysis of the cost of writing a tool better than professional graphic editors that most designers use (Facebook inc's lossy resize or clip isn't good enough quality.). The blocks should be renderable on older phones, newer phones, tablets and desktops. There are standard libraries to allow this.
 BDD is designed for complex systems, and /or requirements that move.