How to Build a Custom Headless Website the Right Way

A story loosely based on real events from the field.

I’ve had a chance to take a step back and re-evaluate yesterdays failing prior to the client demo. I believe that yesterdays failings distill down to trying to accomplish too many small tasks in too short a time frame. Over the course of the last six weeks I’ve put a lot of pressure on this team in order to push the greatest result out of them in the shortest time frame possible. We have a total of five developers that have worked on this project in different capacities in order to move it over the line. Two of those developers have been allocated to this full time and have been working 55 hour weeks over, the last month, in order to meet Tuesday’s deadline. Mistakes were made by the developers yesterday in order to try to make the site as presentable as possible for the demo. We de-prioritized existing, functional bugs in order to try to cram through what appeared to be minor visual changes for the demo. Ultimately we broke our process, and pushing an already tired team that far isn’t fair to them, the responsibility rests with me.

When we begin a project with a near-impossible deadline we have a very specific way we accomplish this that I’ve learned over many years doing this. The basics are, we staff the team conservatively early on, to avoid people duplicating work and stepping on each other’s code. Rather than look to build the entire site page by page with qa stages in between we look to optimize to avoid context switching. Context switching is the speed killer, which includes things like stopping for minor QA bugs, as well as going back to the designs to take second and third measurements. When you are trying to craft components in addition to desiging a CMS that is effectively your database at the same time, aiming for both perfection in information architecture as well as pixel perfection is too many different concerns to focus on at once. We take our early, senior team members and have them lay the foundation for the CMS as well as create a rough layout from the designs. The DOM nodes are expected to be semantic, the data is expected to flow correctly, and the function of those components should be ironed out here. The specifics of typography and spacing are not the focus. We need a solid anatomy before we can begin to think about its form.

The second phase of this is where we begin to add more developers onto the project who can then follow this sound design and put the polish on needed to launch. The issue with this approach, as we have seen, is most stake holders are more interested in the paint and polish than the materials and mechanics under the hood. Ultimately, we aim to "show" something perfect rather than actually "have" something perfect. In the second phase each developer goes back to the design and runs through every component, measuring twice and laying out the proper code across mobile and desktop.

An accomodation I allowed, but a mistake on my part was that I allowed QA to begin despite every page being in this rough state. This led to a series of issues and bugs that cut across pages and components being logged. Rather than having the team continue to work off the designs we attempted to squash the P1 issues. This leads to more of a game of "whack-a-mole" than a systematized QA process.

We ended up with a team of four, rapidly trying to meet a deadline approaching by the hours. One mistake led to more as people tried to undo past mistakes while still fixing the essential bug list. So going forward we are not going to be working off the bug list for the remainder of this project. This timeline was tight to begin with, and its just too tight for a proper QA process. The engineers have to pitch a perfect game and that’s that.

In order to get this project done in world class fashion and still nail the deadline is as follows:

1. We will be maintaining the current staff levels of four engineers.
2. Each engineer will be returning to the figma and applying the “paint and polish” to the design, aiming for absolute pixel perfection. Now that the CMS and function of the site is stable we are able to get back to this properly.
3. Any bug or design change that takes longer than 15 minutes to achieve will be moved to the backlog of “issues” with a time estimate to resolution placed on it by the developer. The goal here is spacing, typography, style. These should all be fast changes, anything more than that, for example a broken carousel will be addressed in isolation. This stage should take no more than 6 hours to complete.
4. At the conclusion of this phase we are going to evaluate what was put on the backlog as well as the total time estimates added up. This should be a relatively small number as major functionality issues should be largely complete at this point. We will then assign a developer to each issue by page.
5. By end of day Friday I will go through the PM tool as well as the git issue board and close all issues fixed by the proper QA process. Any issues that we find further we will be addressing over the weekend. I will assign all remaining issues and we will have two engineers available to field these Saturday and Sunday.
6. By Monday the site will be ready for a round of QA by your team. My team can use Monday to fix any defects found by your team. I will also keep a staff of three on hand for Monday so that we can be efficient here.

This is the proper way to lay siege to a code base and get a custom headless website done properly. The team needs clear heads and they need to be working in isolated parts of the code base to avoid collisions or cross-cutting issues. We need to keep context switching to a minimum and most of all keep the pressure off of them so they can do their best work.

We will begin this implementation this morning, I will also be working with the team closely through this entire process. I will not be available for calls, I will not be available to talk through time tables, my only goal is to complete this project to the best standards that I know my team and I are capable of. You are able to check progress in the staging link. We will be deploying continuously, liberally, and often.

How Can We Help?

Say [email protected]