Building a Multi-Site Website Environment at Edit-Ability

organization
Capabilities
Timing

Situation

In 2009, I successfully founded and built a web design and digital marketing agency. I focused on building WordPress websites for small business clients. I built each of their websites on their own individual WordPress installation, however, found it difficult to design, deploy, and maintain websites at scale. This approach limited my ability to grow the web design line of business and develop new service offerings. As I revamped the company’s service delivery model, I realized that I needed to improve the marketing technology stack in order to develop and maintain websites at scale.

Action

  • Used unique blend of business, web design, and marketing knowledge to create a scalable WordPress platform that supports the hosting & maintenance requirements for 150+ feature-rich websites. 
  • Documented platform usage, creating manuals for each type of administrator as well as end-users.

Result

VALUE TO BUSINESS
  • Increased sales revenue
  • Reduced order-to-delivery process by 2 weeks
  • Increased customer satisfaction
  • Expanded service offering

VALUE TO CUSTOMER 

  • Fully functional pre-built websites at fraction of the cost.
  • Quick-turnaround. Instant site delivery.
  • Easy to add features and functionality at a future date if needed. 

Additional Details

Building a scalable technology platform for small business websites.
 

Small businesses are unique, but their websites have common elements. Based on this premise, in 2010, I decided to flip my model for building custom websites. Instead of building a website for a customer from the ground up based on their needs, I decided that I would start with a basic framework and customize from there. Car manufacturers don’t wait until a customer arrives to engineer a vehicle, nor would I!

Here are some of the actions I took to build a scalable WordPress platform that supported the hosting & maintenance requirements for 150+ feature-rich websites.

When custom building websites, you start to notice a trend: clients request more or less the same features. No matter their industry or type of business, they generally had the same needs.

Here is how I approached gathering requirements:

  • I created a list of the most common features needed by my small business clients. I turned these into very rough user stories, with screengrabs and examples for reference. For each item, I outlined the business goal or outcome and the user goal.
  • I considered emerging web trends and what these clients would likely need as they grew. I added new features to the list or expanded an existing feature.
  • I added authoring and site administration requirements to the list.
  • I had one-on-one meetings with clients to review the list and ask for feedback. I wanted to understand whether the features as written accurate, whether there were any items that I was missing, and what the most critical features were for them. Based on this, I augmented the stories and added to the list.

Here is how I approached organizing requirements (whiteboards and empty walls were my friend):

  • I listed all of the features out on index cards and put them on a wall, grouping them into categories based on desired outcomes. I ended up combining many of the features because there was overlap.
  • I took my revised list of features and added the following:
    • A value score based on how much clients seemed to value them
    • A feasibility score based on how easy or difficult the effort to create them might be.
  • Using both scores, I ranked them. Those that had the highest value score and lowest feasibility score topped the list.
  • Those that had the impact and required greatest effort were evaluated more closely. Some of those were simply eliminated. But others stayed on the list.
  • I also identified which of these were minimum requirements for a website.

With this in hand, I created two more documents:

  • A document which outlined at the highest levels business, functional, and technical requirements
  • A one-page roadmap which laid out the sequence in which loosely laid out an implementation plan. At the time, I did not know enough to build a plan, but I knew what order high-level tasks needed to happen in.

At the end of this process, I had:

  • A rudimentary, but directionally accurate roadmap
  • A high-level requirements document
  • A list of features that were absolutely required for client websites
  • A ranked list of features that should be explored

10 years later:

Looking back on this, I would have done a few things differently:

  • Involved end users. End users were missing from this equation. I would have asked clients to invite their customers to the interviews that I did with them.
  • Created a backlog and user story template. I continued to add to the list of features over time, but did not have a formal way of documenting them or evaluating them.
  • Bring technologists in earlier. I did not bring in my technical experts until after the requirements had been built. My initial feasibility score was a gut score based on what I knew. Having them there earlier would  have made the next step smoother.

In doing this work, I also found an insight which has served me well:

  • Diverse business needs, feature requests. Common denominator is often outcomes. If you can align around outcomes rather than features, success follows.

The first step on the roadmap was to build the technology infrastructure that would support everything. Here were some steps that I took.

  1. I determined that WordPress was the optimal system to build on.
    1. This decision came after reviewing multiple CMS’s and evaluating them against the minimum requirements– both for customers AND for internal operations.
    2. I also tested (and crashed) quite a few CMS’s and even created my own home-built CMS in the process. Nothing beat what WordPress had to offer.
  2. I identified the right WordPress configuration.
    1. Rather than have independent WordPress installations, I chose to build a multi-site network.
    2. I wanted to have multiple client sites under one roof so that my team could:
      1. Maintain, upgrade, and back-up one install only, reducing time and cost.
      2. Troubleshoot and provide support from one place.
      3. Manage billing and account information from one place.
    3. In 2010, WordPress Multisite wasn’t pre-built into the core framework, but I was able to modify the code base and database tables to create the same solution.  
  3. I identified the right hosting partner, paying a premium for a secure hosting environment.
    1. At the time, managed WordPress hosting platforms were not readily available. WordPress sites were hacked regularly, especially on shared server environments. I once spent 17 hours non-stop troubleshooting and rebuilding sites as a result of a vulnerability. I was determined not to let that happen again!
    2. Based on my prior experiences with web hosts and my client’s requirements, I made a list of factors to evaluate hosting providers.
    3. I interviewed hosting providers and even tested various environments out.
    4. I selected a managing environment which was much more expensive, but eliminated the headaches and risks that I’d previously experienced. I also negotiated a stronger support agreement with them.  
  1. I completed the setup and installation for the platform.

Note: Several years after I shared my process and approach at a WordCamp Conference. Here is a document with more details about my approach:

  1. Building the Technology Platform

After laying the concrete (i.e. setting the basic infrastructure up), it was time to start building and customizing the WordPress network to meet my needs.

Completing this took almost 6 months. It was incredibly challenging because the core business had to continue to operate, while building the new infrastructure. Initially, I tried to assign staff to both current customer work and new platform work. This did not work! Eventually, I hired a team of freelancers and dedicated them building the new platform.  

So, what did we do?

There were three main steps in my process, although it wasn’t exactly linear.

  1. Developed front-end user experience based on user stories
    1. From user stories, we had a list of templates, components, and web elements that needed to be built.
    2. We developed a master parent theme, which included core functionality, templates, and components.
      1. The HTML code had a responsive grid and was built in a modular fashion. Instead of using multiple specialty templates the way that many WordPress themes were using at the time, we had 3 templates.
      2. We created shortcodes to manage more complex designs and layouts.
      3. We were extremely careful about how we structured our CSS. The parent theme had to be “vanilla” so that it could be customized by each site.
      4. We used the latest frameworks and code libraries from third party vendors.  
    3. We develop a child theme which inherited the parent theme’s structure, but could be customized independently. Each child theme had independent style sheets and elements that could be manipulated, while the parent theme remained the same. This would allow for:
      1. Multiple sites to use the same parent theme, but have a different look
      2. Multiple sites to be updated with new features that were instantly made available across the network
  2. Developed backend site administration and author experience based on user stories. We added elements that enabled clients and their team members to manipulate their site without needed development support. In general, WordPress has much of the functionality required innately, but to meet the minimal requirements, we needed to build and/or find plugins that delivered more complex functionality.
    1. Built a theme options panel which enabled the user to manipulate the style, color scheme, and layout of theme. This drastically reduced design and development time because someone from our team or the client themselves could customize their site via the admin panel.
    2. Enable users to map their own custom domains to their site
    3. Enable users to add Google Analytics tracking to their site
    4. Enable users to add custom forms to their site
    5. Enable users to manage SEO elements– both at a global site-level and at a page-level

After laying the concrete (i.e. setting the basic infrastructure up), it was time to start building and customizing the WordPress network to meet my needs.

Completing this took almost 6 months. It was incredibly challenging because the core business had to continue to operate, while building the new infrastructure. Initially, I tried to assign staff to both current customer work and new platform work. This did not work! Eventually, I hired a team of freelancers and dedicated them building the new platform.  

So, what did we do?

There were three main steps in my process, although it wasn’t exactly linear.

  1. Developed front-end user experience based on user stories
    1. From user stories, we had a list of templates, components, and web elements that needed to be built.
    2. We developed a master parent theme, which included core functionality, templates, and components.
      1. The HTML code had a responsive grid and was built in a modular fashion. Instead of using multiple specialty templates the way that many WordPress themes were using at the time, we had 3 templates.
      2. We created shortcodes to manage more complex designs and layouts.
      3. We were extremely careful about how we structured our CSS. The parent theme had to be “vanilla” so that it could be customized by each site.
      4. We used the latest frameworks and code libraries from third party vendors.  
    3. We develop a child theme which inherited the parent theme’s structure, but could be customized independently. Each child theme had independent style sheets and elements that could be manipulated, while the parent theme remained the same. This would allow for:
      1. Multiple sites to use the same parent theme, but have a different look
      2. Multiple sites to be updated with new features that were instantly made available across the network
  2. Developed backend site administration and author experience based on user stories. We added elements that enabled clients and their team members to manipulate their site without needed development support. In general, WordPress has much of the functionality required innately, but to meet the minimal requirements, we needed to build and/or find plugins that delivered more complex functionality.
    1. Built a theme options panel which enabled the user to manipulate the style, color scheme, and layout of theme. This drastically reduced design and development time because someone from our team or the client themselves could customize their site via the admin panel.
    2. Enable users to map their own custom domains to their site
    3. Enable users to add Google Analytics tracking to their site
    4. Enable users to add custom forms to their site
    5. Enable users to manage SEO elements– both at a global site-level and at a page-level

10 years later

  • Essentially, the team built a design system (although I didn’t know it was called this at the time)
  • Hindsight is 20/20. I didn’t make the right decisions when it came to the use of 3rd party libraries and that created problems down the line.
    • For one, I decided to custom build the CSS grid, resets, and media queries when frameworks like BootStrap and Foundation had some of the functionality built in.
    • Second, I some of the third party javascript vendors that I used stopped supporting their libraries. This meant that we had to support, modify, and maintain them with each new release.
  • While I am happy that WordPress has evolved, I am kind of jealous of the new features that come out of the box. I feel a bit like the grandparent that talks about how it was in the “old days”, but at the time that I built this network:
    • I had to manually built the network, creating and modifying tables in the  WordPress database and adding them to the config file. There weren’t many people doing this and not a lot of support. Now, there is WordPress MU, which allows you to create a network and add sites with the click of a button. Today, this is more common and support is ubiquitous.
    • I used shortcodes in a way that I thought was revolutionary at the time. My shortcodes weren’t just small web elements like buttons, they were entire content blocks which could be stacked. Coding these shortcodes and building the right HTML structure was challenging. Updates were difficult. Today, there is no need for this because there are many visual editors that do what my shortcodes were intended to do.
    • I used theme options to manipulate site elements. These options and the theme options panel had to be built from the ground up. Now, WordPress’s Customizer functionality allows much of this out of the box. And it can be easily extended to add additional items.
  • I had no way of knowing that I would have to work on something similar at a larger scale. Thinking from a systems perspective, figuring out templates and components across 100s of websites, and building a design system are all skills that I honed here, but am using in more recent roles.
Just having the platform created efficiencies that allowed me to scale the business. Building plugins and seeing how flexible the platform was inspired me to search for ways that the platform could help in areas outside of design and development. My goal was to systemize the business as much as possible and free up time for me to focus on more value added activities. Some of the areas that I focused on for automation were:
    • The order management process. This included: account creation, payment integration, and instant site creation. Once the user completed this process, notifications were sent to sales, accounting, and project management staff. Additionally, new information was visible within the staff’s administration panel.
    • The support or helpdesk process. Clients could submit their help tickets within their admin panel. Support staff could see it instantly and sometimes resolve it via their admin areas. And I could monitor the work.
    • The backup process. Building such a large network was risky. I feared that any number of unseen circumstances could bring it down and leave hundreds of clients in the dark. This fear never manifested, but if it did, I was ready. We used a backup plugin and process to take snapshots of the network and databases, so that we could rebuild it within an hour if needed.
    • Architecture and guidelines. This was not a platform modification, but one that saved a lot of time. I documented the platform architecture and guidelines for usage and posted them in the staff admin area. This was important to keep us all on the same page. Also, when new development freelancers were onboarded for a client’s project, they understood the development environment and could make updates in the right way.
       

organization

Capabilities

Timing

SITUATION

ACTION

RESULTS

Find this information interesting?​

There is more where that came from!

Scroll to Top