The following are a series of reflections on the philosophy and design approaches behind creating a massively scalable web production CMS platform. They were written in the context of client-side scalability that should allow customers to continue extending their online solution without the need for constant middle-man hassle.

On a note of necessary clarification, we are absolutely not against web development middle-men — we simply feel that many contemporary developer-designers would do well to move on from last millennium models, up-skilling and optimizing their approach in providing professional-grade scalable online solutions to their customers. You can accomplish much more in the same amount of time, and provide an easier environment for everyone — and we are a catalyst of change!

For the better part of the last two years, I have worked on creating and developing an abstracted CMS platform with a strict separation of the core "engine" and modular applications, featuring a templating and content rendering model that among other things:

1) Provides variant "data templates" for symmetric database content provided by modules (e.g. full size, summary, list, index, thumbnails, etc.).

2) Provides override templates on a per-module basis to tailor content presentation on a per-application basis while otherwise using standard template bits.

3) Separates CSS (all styles) and HTML (wireframes), allowing "sub-theme" CSS and image folders to provide variants to each "base skin".

4) Separates language from HTML templates, allowing multi-language options, and per-module overrides to standard "elements" along with derived language strings.

5) Allows skin and page wrapper selection both on a per-module and a per-page basis. (Per-URL criteria coming up.)

6) Provides a browser-based drag & drop page organizer with static (WYSIWYG editor + image uploader) and dynamic content (everything from modules and database) customization, further providing an extensible grid for all available dynamic content fetching options (multiple scopes, quantities, etc.).

7) Allows for unlimited amount of "content base" units that can be applied as backgrounds to all types of content units, along with column and row combinations thereof.

8) Features a number of additional builders (feedback forms, data sets, profile field sets, multi-level menus, etc.) that allow you to customize the site in-browser.

... and so on ad infinitum the deeper you dig, but the architecture has evolved along these general lines in providing a production environment where developers, who know what needs to be done, can efficiently and in a well-rounded manner meet all their production needs, and provide their clients with solutions that can scale with ease well into the future.

Granted, there are T's to be crossed and I's to be dotted, but I feel this approach is the only viable option if we intend to remove the unproductive "middle-man hassle" from the industry, providing true client-side future scalability with our software solutions. It has definitely spared me from a vast amount of headache and wasted "fiddling time" in providing customer implementations and updates to sites deploying the platform.

Overall, my experience is that anything you hard-code will return with vengeance and bite you in the arse in the future, and therefore it's more expedient to only create abstracted implementations and then tune the separated configuration, use the generic builders, and be done with it without getting your hands dirty all over again.

The subsequent end result and its output will also be tidy and organized, because all interface and output combinations adhere to the same abstracted and symmetric patterns. In fact, I hate the hardcode-headache enough to code my own generic applications and extensions to whatever may look like I may need to do it more than twice in the future. 

This approach will continue into the future, moving us all further towards an emerging trend of dynamic, flexible and scalable online solution environments.