The Tools We Use

Follow us on LinkedIn for our latest data and tips!


We develop with many different tools at appendTo. We have resources for everything from project management to preprocessing. While these tools change over time, we’ve found our current setup works well for us. In this post, I’m going to cover how we use Pivotal Tracker, GitHub, Grunt, Bower, and Stylus. I’m also going to mention a little bit about our deployment process.

I should also mention this before we start: this is only a small sample of what we use. This doesn’t represent a boilerplate or how every appendTo project is built. These are just some of the tools we use and how we incorporate them into projects.

Pivotal Tracker

Because we use the agile methodology at appendTo, our project management application of choice is Pivotal Tracker. We don’t just expect our engagement managers (EMs) to understand the agile process. We train all of our team members on how to effectively use these principles from start to finish.

Pivotal Tracker helps us manage our projects using “stories” (or tasks), “sprints”, and more. Through the web app, we can easily set up new stories, attach Photoshop comps to them, have discussions, and assign them to coworkers with ease. Here’s a run down on what this workflow looks like:

  1. We have a number of stories that need to be accomplished in the current sprint.
  2. We divvy the stories up – based off effort required – between team members on the project.
  3. Each team member works on their tasks and marks the item as “Delivered” when it is ready for review.
  4. Another member reviews the work and can either “accept” or “reject” the story.
  5. If a story is rejected, the reviewer will provide some feedback on why the story needs more work.

Pivotal Tracker works well with Git, our version control method of choice, and GitHub, our remote repository host.


We use GitHub for hosting our repositories. GitHub works great for us because they’re well-known for collaboration, bug tracking, and an impressive track record for stability.

GitHub also allows us to have thorough code reviews. We often leave each other comments on specific lines of code about optimization and how we can better organize functionality. This level of granularity helps us to enforce our standards and practices and make sure we’re all improving.

We follow a fairly standard GitHub flow approach to our builds. That means a couple of things regarding our repository setup: anything in the master branch is deployable, always create branches for new features, send a pull request when the code is ready to be reviewed, and then merge the branch into master to be deployed via TeamCity (our CI/CD platform).


We automate a great deal of our workflow when we start working on a project. It would be painful to manually perform tasks like compressing CSS and JavaScript, not to mention completing all these tasks across team members. Because of this, we like to rely on Grunt to run tasks for us.

The tasks we run greatly depends on the project needs. However, some of the ones we typically use are JSHint for code linting, watch to automatically run tasks when files change, Uglify for minifying code, and Mocha for running Mocha tests against our JavaScript.

Once we have our tasks installed, we set up the code to get them working within our Gruntfile. Then we’re able to run commands like $ grunt, $ grunt serve, or $ grunt test in our command line to perform any tasks we need within our project. Because our Gruntfile is part of our repository, any team member with Grunt installed can run the same commands from their machine, too.

Gulp vs. Grunt

As I said earlier, this is our current setup. We don’t want our skills to get stale, so we try new tools and processes as they gain traction. Gulp is a Grunt competitor that has grown quickly over the past year. Gulp is similar to Grunt, but uses Node streams and favors small, single-focused plugins.

A Grunt plugin may have several responsibilities while a Gulp plugin is single-focused. For example, instead of using one plugin to compile .scss files and compress the output, you would use one plugin to compile your code and another to compress the CSS output. Separating these concerns enforces Gulp’s mantra of “code over configuration”.

While Gulp is a great build system, we’re mainly using Grunt because of its maturity in the development community.


Bower is a front-end package manager that allows you to search for packages like jQuery, Picturefill, and Flexslider and install them from your command line. This management setup makes it easy to install modules and plugins into your project with very little effort. For example, to install jQuery you simply run $ bower install jquery -S. This searches the Bower package registry and downloads jQuery to a bower_components/jquery/ folder. The -S flag will save the package information to your bower.json file.

Bower can also update packages from the command line as well. Just run bower update in the project root and Bower will automatically update any packages that have a different version number from the bower.json file. This is useful because one command helps us stay on top of updates and ensure we’re on the latest stable version of any dependency. On top of this, we can also configure Grunt to update our Bower packages for us.

For much more information, Bob Yexley wrote a great article on how to use Bower and set it up within your project.


There are numerous CSS preprocessors out there that can provide powerful CSS functionality like variables, loops, and mixins. We’ve used many different preprocessors at appendTo, but our preferred choice is Stylus.

Stylus is a Node-based preprocessor. We favor it over other preprocessors because it is extremely fast, flexible, and fits nicely within our other Node tools. Although we do prefer Stylus, we have used Sass, a Ruby-based preprocessor on a number of projects.

Stylus and Sass are very similar, but differ largely in syntax and what they were written in. For instance, Stylus can be written without colons and semicolons, while Sass is more strict about formatting. We prefer to write Stylus using colons and semicolons so the code looks closer to standard CSS and is a bit easier to read.

We’ve heard great things about the Nib library (similar to Compass for Sass), but we’re content with the power of imports, mixins, and functions that Stylus has built-in.

Continuous Integration/Continuous Deployment (CI/CD)

We use TeamCity for our CI/CD workflow. This allows us to do two things with our code: test our site before a deployment and then deploy our successfully tested code to the server.

Within TeamCity, you specify the branch you want to deploy from. It will then automatically detect any changes to that branch and begin the testing process. TeamCity tests our code through tests we’ve set up and then deploys the site if all tests pass. If they don’t pass, we’ll receive a notification telling us where the failure occurred so we can correct the issue.

This approach is very beneficial. It helps us ensure that anything we deploy won’t cause the site to break for users. This strategy is especially valuable because our projects typically have several developers working on code together.

For more information on our approach to CI/CD, Jordan Kasper will soon be posting an article dedicated to our setup. He’ll go into more specifics on how we use TeamCity across all our developers check out Jordan Kasper’s post, “Continuous Integration: A View into appendTo’s Process“.


This is just a small sampling of what we use on appendTo projects. Hopefully this helps you get some insight into what works for us and some ways to improve your current workflow. It’s ever-changing and we’re always looking to improve the ways we work and the tools we use. What tools do you use?