Building a Marketing Technology Platform for Small Business Websites




In 2009, I successfully founded and built a web design and digital marketing agency that focused on building WordPress websites for small business clients. At the time, I created each website on its own individual WordPress installation, but I soon 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 our portfolio of marketing technologies in order to develop and maintain websites at scale. Although small businesses are unique, 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 from the ground up based on a customer’s needs, I would start with a basic framework and customize from there. After all, car manufacturers don’t wait until a customer arrives to engineer a vehicle, and neither should 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.

Gathering Requirements and Developing User Stories

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.

  • 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.
  • 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.
  • A high-level requirements document – A document which outlined at the highest levels business, functional, and technical requirements
  • A rudimentary, but directionally accurate roadmap – 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.
  • A list of features that were absolutely required for client websites
  • A ranked list of features that should be explored

Setting up the Technology Infrastructure

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

This decision came after reviewing multiple CMS’s and evaluating them against the minimum requirements– both for customers AND for internal operations.

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.

  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.
    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.

Sharing My Setup at a WordCamp Conference

Several years after I built this structure, I shared my process and approach at a WordCamp Conference. Here is a document with more details about my approach. Using WordPress Multisite to Power Your Hosting and Design Business 

Building the Technology Platform

After setting up the basic infrastructure, it was time to start building and customizing the WordPress network to meet my needs. This task took almost 6 months to complete, as it was incredibly challenging to balance building the new infrastructure while keeping the core business operational. Initially, I tried to assign staff to both current customer work and new platform work, but this approach proved ineffective. Eventually, I hired a team of freelancers and dedicated them to building the new platform. So, what did I do? The process involved three main steps, although it was not exactly linear.

  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

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
  • I documented the platform architecture and network maintenance best practices for my team. 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.
  • I also created a document to help site administrators and content authors build their pages or update their site design. This allowed them to self-service and lessened their need for support from our team.

Building Business Automation

The platform itself improved efficiency and allowed me to scale the business. This inspired me to find new ways to use technology to improve business operations beyond design and development. My objective was to systematize the business as much as possible and free up time for more value-added activities. I focused on automating the following areas:

  • The order management process. This process includes account creation, payment integration, and instant site creation. After the user completes this process, notifications are sent to the sales, accounting, and project management staff. Additionally, new information becomes visible within the staff’s administration panel.
  • The support helpdesk process. Clients can submit their help tickets within their admin panel. Support staff can instantly see and sometimes resolve the tickets via their admin areas. I can monitor the work.
  • The network backup process. Building such a large network was risky. I was afraid that any number of unseen circumstances could bring it down and leave hundreds of clients without service. Thankfully, this fear never materialized, but I was prepared nonetheless. We utilized a backup plugin and process to take snapshots of the network and databases, allowing us to rebuild it within an hour if necessary.


I successfully built a WordPress platform that eventually scaled to supported the hosting & maintenance requirements for 150+ feature-rich websites.


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


  • 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

🤔 A Reflection: 10 Years Later 

Looking back, 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.
  • Less reliance third-party libraries. Less custom work. In hindsight, I didn’t make the right decisions when it came to the use of third-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 already had some of the functionality built in. Second, 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.

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

  • Align around outcomes. Diverse business needs, feature requests. Common denominator is often outcomes. If you can align around outcomes rather than features, success follows.
  • Small scale → Large scale. 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 hundreds of websites, and building a design system are all skills that I honed here, but am using in more recent roles.
  • Stay on top of new features (predict them where possible). 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 build 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 that 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.








Find this information interesting?​

There is more where that came from!

Scroll to Top