On Wednesday, April 4 we launched 17 websites all at once. They were our 17 Served sites, which included 12 previously existing ones and 5 brand new ones, all with a fresh new makeover. Development was completed two days prior to launch, and started five days prior to that, with a team of only three front-end developers.

Five days to build 17 websites?! You heard right! With heavy utilization of some advanced Sass’ techniques, we built 17 websites in 5 days, a feat we almost definitely could not have accomplished without the power of Sass variables, partials, logic and imports.

Each Served Site is composed of four pages: the gallery, the project page, the joblist, and the about page. Structurally, all of the Served sites are identical: columns, font sizes, element widths and heights, etc. Since only their colors differ, the best approach would be to split structure from style.

A Served site starts of with a small subset of CSS files from the Network for a few things like the project covers and the site footer, which are the same on both the Network and Served sites, so we weren’t starting completely from scratch, only mostly. Two additional CSS files are included for each relevant network file: one for the Served structural base and one for the specific site (colors). Here’s what the very first newborn Served site looked like before we give it any structure or colors:

The first task was to set up the base structural CSS, since this would be used across all the sites and we would never have to touch it again after it was written. There isn’t really any cool Sass stuff at this point, but it paves the way for the good stuff later. Here’s a sample of our Sass file structure for the Served sites at the start of the project:


All of these files contain ONLY structural CSS for their sections: no colors, no font families. Here’s what our newborn Served site looked like after we finished the base CSS:

Of course, the major defining characteristics of each Served Site come from its color scheme and its logo. In a previous era, making a new Served site meant copy-and-pasting the CSS from a previously existing site and hoping the rules were split up (and maybe even commented!) in a way that would make find-and-replacing the right hex codes easy. It was an okay solution for a few years ago, but now that it’s THE FUTURE, we do things the Sass way! Using a creative mix of partials and imports we were able to expand the idea of “just replace the hex codes and voila, new Served site!” into a much simpler process of defining variables and printing them out.

The next and probably trickiest part of the process was figuring out a way to not just define variables for every site, but do it in a way that did not involve copy-and-pasting any CSS. Because you can use the variables defined in one partial in a completely separate partial as long as they are imported within the same file, we made a file full of variables for hex codes, borders, box-shadows and other various visual styles, and a separate file that would print them all out. Our file structure then came to be:


Our served.scss and base folder are the same as before, but we’ve added some new things: a _served.scss partial, a _colors folder containing more partials, a typopgraphy.scss, and a typography folder of directly-compiling Sass files. The _served.scss partial and anything within the _colors folder are responsible for printing out the CSS using the variables defined in typography/_colors.scss. Like so:

A snippet from Typography’s _colors.scss file:

$base_link_color: #000fff;

Then, in _served.scss:

a {
  color: $base_link_color;

And finally, in typography.scss:

@import "typography/colors";
@import "served";

See what we did there? Our _colors partial defines a hex code which another partial then prints out. At the end of all the customizations — and we left room for pretty much anything to be customized — each Served site’s _colors file contains about 200 variables. We even have a variable containing the name of the Served site for use in image paths. Here’s a more robust snippet of the file:

$served: typography;

// Typography-specific
$yellow: #fff100;
$dark_yellow: darken( $yellow, 42% );
$invert_icon: true;

// Basic Color Variables
$body_background_color: #222222;
$base_color: $yellow;
$hover_color: #fff;
$header_background_color: #000;
$header_color: #fff;
$primary_border: 1px solid #3f3e3d;

// Header
$super_header_link_color: $yellow;
$more_served_dropdown_primary: #414141;
$more_served_dropdown_secondary: #272626;
$dropdown_active_link: #000;
$tooltipi_link_color: $yellow;

And the remaining compiling Sass files for the Served site would consist entirely of an import line for the _colors.scss partial and an import line or lines for the related CSS. For example, typography/project.scss:

@import "typography/colors";
@import "_colors/project"
@import "_colors/_project/covers"

or typography/joblist.scss:

@import "typography/colors";
@import "_colors/joblist";

So essentially an entire Served site boils down to just one file full of hex codes.

How we did it so damn fast

Obviously having one file of hex codes to define an entire site is a significant way to speed things up. We made a “template” folder to use as a jumping-off point for any new Served site. We also defined a few site-specific variables at the top of each _colors.scss that would be re-used throughout the file. We also used some of Sass’ color functions like darken to reduce the amount of hex codes that would need to be defined. As an example, the Follow button’s hover and active states are calculated with Sass based on its default gradient colors. For the most part, the only thing that isn’t an @import for any given Served site is a CSS rule to define the width and height of the site’s logo.

But what about a one-off Served site?

A couple of our Served sites, such as R/GA: The Digital Age and ID Magazine, are more unique. Both of them have completely different footers, and RGA has special sidebar elements. But our setup still allows us the freedom to add any one-off CSS we need. Just drop the additional styling in whichever site-specific Sass file requires it and you’re good to go.


This was our first time using Sass modularity to such a high degree, so it was very experimental and an incredible learning opportunity for us. In hindsight, there are probably still some things we could streamline:

  1. The logo: Make them all have the same dimensions. They vary by a negligible amount, so a few extra empty pixels may be worth the decrease in development time.
  2. Naming conventions: By the time we were done, the _colors files held more than just colors, including the name of the Served site, a boolean variable to invert the icon on the Follow button, and some borders and box-shadows.
  3. Unused CSS: On a site like RGA or ID Magazine, they’re loading the structural CSS for the Network footer even though they don’t use it. Perhaps modularizing the base structural code even further would be a benefit in these situations.
  4. The future: How cool would it be if we built a tool for the front-end that would allow a designer to select colors in the browser and generate a Sass file of hex codes to create a new Served site without the need for a developer?

Overall, the process was a huge success. Three developers working together to create 17 websites in 5 days without sacrificing quality is a pretty impressive feat, and while we made great use of a lot of different parts of Sass, it feels like we are only beginning to scratch the surface of how we can make Sass work for us.