How We Build Websites 

SKYCATCHFIRE builds a lot of websites. Last year, our team of 8 launched over 30 sites. We did that in spite of a global pandemic during one of the wildest years in recent memory. Throughout all of the excitement of 2020, the websites we built were some of our best ever based on the metrics we care about: client happiness, timeliness, budget, and performance. Here’s an overview of the process that enables us to operate lean while delivering work that our team and our clients are so proud of.

Early on we were hesitant to try and nail down a process. The thought of it seemed too permanent. What happens when we find a better way to do something? How are we going to keep up with it? It seemed daunting to maintain a template when preferences and best practices seemed to change with each new project. It turns out that it was daunting but so liberating. Regardless of how fluid your process is today, a template sets the bar for each new project and it improves each time it’s used. It’s a compounding benefit that has changed how we work.

The structure of our project teams is intentionally fluid. Most of the time, projects start with 1 or 2 developers. As times go on, members can move on or off based on progress or new project demands. This means we may start with 1 developer and end up with 3 in order to make up time or build a new feature. This fluid approach is possible because we believe our team should be able to move from one project to another and know that the process remains the same.

The board

A template doesn’t need written in stone. We call ours the Starter board and it lives in Trello. It guides how we start each project and outlines nearly 100 tasks to help make a new project at least as good as the last. It’s a living board that we’re constantly adding to or improving based on new things we’ve learned or decisions we’ve made on a recent project.

Have you ever nearly finished a site and shared it only to realize you forgot to update the page title, description, share image, favicon? We assumed that if we were forgetting that little detail there were probably more important things that were missed too. It was probably a few missed favicons or share images that finally convinced us that this was a good idea.

Lists

Each project board has the same six lists. Consistency is especially important if your goal is to enable developers to move between multiple projects. Because the team needs to be fluid, the process needs to be the same across every project we build.

By keeping our process the same across all projects, we’re able to move in and out of projects with little spin up time. This is a large part of our small team’s success.

Keep List

A project board begins as a clone of our Starter board and then becomes our hub for all things related to that project. The Keep list contains anything we need to reference for the project including Estimates, Mockups, Basecamp link, and BugHerd link. A new team member should be fully capable to join a project team by just receiving access to this board.

Team Review List

As we move through a project questions will come up. Should we do this? Do we need an improved design for this? Does this task fit in the timeline? Any time a task is blocked or needs further conversation we move those items here. Team Review allows us to keep a running list of things that need to be discussed or reviewed before they can be completed.

Tasks List

This is where the magic happens. Tasks ready to work on live here. Tasks include details and requirements but are typically not assigned to anyone. Each developer determines the next best thing to grab based on timeline, relation to a previous task, or challenge level.

In Progress List

It’s nice to be able to see what’s being worked on. When someone grabs a card they assign themselves and move it here.

Ready for Review List

As tasks are completed and ready to be merged they’re moved here. Along with moving the card, a Pull Request is created to notify the Slack channel.

Done List

Once the feature branch is merged the card owner moves the card to Done. Once a card lands in this list it’s here to stay. New issues become new cards.

Testing & QA

We’ve tried collecting client feedback in a lot of different ways. We’ve tried spreadsheets, Basecamp, and many others that I’m still trying to forget. Today, we use BugHerd.

In the past we assumed that because a project started in Trello everything needed to happen there. As we moved through the different phases of a project we kept everything on that same board. It seemed like a good idea to log QA for a component on the same card we used to develop it. The problem with that approach was that cards grew and grew. Progress was hard to determine because while work kept extending, the number of cards wasn’t changing.

BugHerd gives us a new board for QA. It’s refreshing and BugHerd makes it easy to collect the helpful details without training everyone to be a professional QA Tester. Using the browser extension you just click on an issue to add a comment. BugHerd logs the important details, grabs a screenshot, and makes a card on the new board dedicated to testing.

EODs

We all work on different projects so a traditional standup meeting isn’t very useful. Instead of a meeting, we share our updates in a Slack thread that is automatically created at the end of each day by skybot.

Communication

Most of our project communication happens in Slack. There are a few ways we keep that organized like insisting to use channels instead of direct messages, using threads, and only pinning a link to the project board for that channel. Too many private messages means the rest of the project team is out of the loop or unable to help. Too many unthreaded messages means a lot of distractions. And too many pins become noise that no one will see.

We also connect Invision and GitHub to the project channel. Cards in the Starter Board remind us to hook these services up at the outset of each project.

Code Reviews

Each feature is a branch that becomes a GitHub Pull Request that’s then reviewed by another developer on the project. Code reviews help keep the project team informed about changes and catch mistakes before they reach QA.

Discussions & Calendar

Basecamp is our communication hub for each project and we route all key decisions, questions, and information there. We invite the client here as well so that adding new members to a project is easy. Basecamp also serves as our project calendar to identify key milestones against the target launch date.

A link to Basecamp lives in the project board’s Keep list making it easy for anyone to find.

More brainpower

Small teams can do the work of a big team when working with a proven process. Operating without one requires a lot more brainpower to keep the fundamental things straight. Without one, simple things can be missed. We’d rather spend time working on new things knowing that requirements like share images and favicons are already accounted for. That’s what we’ll keep doing as we continue to evolve our capabilities and adapt our process.