Structure and Process

From the Start.

We take on projects of all sizes. Though much of our work involves updating, maintaining, or rebuilding with WordPress, we work with a variety of configurations and environments. No matter the project though, the overall tools and process are the same.

Version tracking, local and remote test environments, frameworks, and vanilla code are all considered and actively evaluated for both logical and uncluttered workflows as well as optimized well and preforming sites/apps.

Trello currently in use, Jira also preferred, Asana less so.

Process: Strategy, scope, sprint. 

  • Strategy: We can either work with existing strategy or help plan how to achieve specific goals to build audiences or reduce technical debt.
  • Scope: With every project, but especially multipart developments, we drill down the scope right into small details with just enough flexibility to avoid surprises during development. The same scope is reiterated as needed.
  • Sprint: Where possible, we prefer to prioritize tasks by value and importance then arranged into sprints following Agile methodology.
SourceTree is the go-to but CLI is sometimes required.

Tools of the trade: Test sites, GIT, Frameworks.

With all projects, we set up a least 1 test site for end user review before pushing to live environments. Further, we use GIT repositories (even on solo projects) that not only track changes but also release via SSH or sFTP. Our repos are both specific and clean as possible, we do not track content and commit meaningfully. 


  • HTML: As much as possible we work in the latest specs using roles, semantic tags, and proper encoding for translation. Accessibility is considered from the start with new projects and adjusted as possible with further updates.
  • CSS: SCSS via Grunt for maintaining sanity and proper minification for release. 
  • JS: Although jQuery was essential at one time, we've been moving more towards vanilla as the extra bytes often are not needed. Vue.js, React, Angular aren't a daily part of our setup yet, but are being explored. Last, CoffeeScript is in limited use but can be tricky for larger projects where some developers may not be familiar. 


  • PHP via an *AMP or *EMP is our most common arrangement. We are throughly platform agnostic but generally build on Unix and deploy to Linux.
  • With each back-end implementation we focus on how best to read from the APIs needed, manipulate and store the data, and run algorithms over both stored and recent data efficiently. Although PHP isn't always ideal, it preforms well when packaging, wide use, and quick prototyping of UX/UI are core elements.
  • Although Composer can wrap up a number of packages to make PHP easier, we've found Laravel forms a solid base for sites that either don't need a CMS or for API building. In fact we have a Laravel app reads Google Analytics on a schedule then automatically outputs stats and actions.
  • Node.js too is in use with Laravel and Redis as a bridge between our app and our Chrome extension handling realtime WebSocket connections. 
  • We have build 1-2 extensive redesigns in Drupal but often caution it's implementation unless the use is fully understood. We've found Drupal can be maintenance and administration heavy. 
  • We do use Ruby (on Rails) both for packages and as a framework for a live site but currently aren't looking to expand or explore it's use. 
  • WordPress is our CMS of choice. Although we are evaluating it's long term use, users of all levels are comfortable organizing content, often new functionality can been implemented with plugins or other light development, and even sites with larger catalogs of information can be handled if planned well. We've transitioned thousands of pages of raw HTML into WordPress posts, moved whole Joomla and Drupal sites, (re)built plugins, and taken advantage of the API to further extend the site.
Plugin initialization.


As explained above, much of our projects revolve around straightforward content such as blogs or more in-depth informational sites that can use interconnected taxonomies. A few techniques from our extensive WordPress work:

Multiple methods for pulling themes, this using an include.

Themes, thought through.

  • Preference is a clean Parent theme, however we have also modified Child themes as needed and used Genesis or other theme builders for expedience. 
  • If SCSS wasn't there before, add it. Unless there's a strong reason not to, we believe in upgrading a site's structure during the lifespan.
  • Dequeue, enqueue. WordPress don't always handle scripts and styles cleanly, look at the recent emoji code for example. Time permitting, we clean up theme output.
So many extra scripts…

Plugins, installing and keeping them under control.

  • Dequeue, enqueue, again. Plugins don't always handle scripts and styles cleanly, look at admin.js' for example. Plugins often need to be wrangled so page speed doesn't suffer.
  • ACF, WP Migrate DB Pro, Contact Form 7. A standard set but always reevaluating. Also, the fewer the better. Deleting, not just deactivating, unused plugins and regularly updating if possible are important to us. Also, we keep track of liveliness. If a plugin goes dark, we look for alternatives to avoid security issues.
  • functions, Hooks, Callbacks, Hooks, Modifying. Modifying plugins can be dicey but is necessary for advanced use. As much as possible we stay in bounds and work with the plugins without modifying. As a last resort, we version the plugin, update often as possible, and change the code as needed.

v0.9.5 February 27, 2018