How we built our site

Web development
20 November 2019
Dom Smith
Dom Smith

Spoiler: we didn''t use WordPress! This may seem surprising coming from an agency who build predominantly WordPress sites, but we have good reasons. We want to grow and develop - and you can''t do either of those without trying something new.

Our site is built by a static site generator (SSG), and it''s also a single page application (SPA). We''ve used the following to accomplish this:

That''s a bunch of funny made up names isn''t it? Well I’ve broken up how we’ve made this site by the build, managing content, automated hosting, handling imagery, and styling it up.

The build

The main one in that list is Gatsby. If you''ve heard of anything like Jekyll, Nuxt or Hugo, then you''ve already got a good idea of what this is - it’s an SSG.

An SSG is something that takes some data and creates website files ready to be viewed ahead of time. How or why is this different to anything else? Well, let''s look at how WordPress (which isn’t an SSG) might handle someone accessing a page:

  1. It takes the url from the user’s request, and works out which code to use for the page.
  2. That code then runs - for example, if it was to list your blog posts, WordPress now needs to query its database for your latest posts to get their titles, thumbnails, and urls.
  3. Finally the code uses the data it has collected from the database to create the final HTML (in this case, to build that list of blog posts).

Now imagine this kind of thing happening for every dynamic portion of your site, such as the sticky header, footer and all your case studies or testimonials. You can see how this could take a while? Well this normally happens every time someone accesses any WordPress page.

Note: I''m not saying how WordPress works is bad; there are many benefits to WordPress, more than I can mention here that make it suit different types of sites much more.

In contrast, our site only ever does these calculations when some of our content or code changes. So when someone accesses one of our pages, this has all been worked out already. What’s even more awesome, is when any links you click after that, Gatsby gets the next page’s data and updates the screen for you, so you’re not even technically changing webpage. That’s the SPA part working it’s socks off, making it so quick.

We’ve set this up by making our CMS (Forestry), tell our hosting (Netlify) when our content changes to rebuild our site. Rebuilding our site is when Gatsby kicks in. Gatsby collects our content and code, does some magic and works out every webpage for our site in one big go.

Well this probably sounds like a load of effort, is it really worth it?

I might be biased here, but I think it is. Initial page loads and transitioning between pages is ridiculously fast with Gatsby. It’s also a lot of fun to develop with too - you can play with creating fun animations like our “blob” page transition that isn’t really possible on standard sites.

Managing Content

As previously mentioned, we’ve used Forestry for our CMS. What’s particularly different is that our content gets stored in the same codebase as our site. Normally, with a site like WordPress, this would be stored in a database. By having a project stored in source control (such as Git - we use GitLab), we can have almost every aspect of our site sit in one place (our repository), and have backups showing every single content and code change going back to the very start of development.

One of the biggest drawbacks from being a SSG, is that because we have to rebuild the site every time some content or code changes, that means we have to wait until it has been rebuilt to see the new changes. That means clicking save, waiting two to three minutes, then checking to see if we’ve broken everything (or not). We’ve set up notifications to let us know when it’s finished, but comparing that to WordPress where these things are much more instant, is definitely a downgrade in that respect.

Another big drawback of a lack of database is not being able to handle large amounts of data efficiently, but for the contents of a site like this, we’re happy to accept these consequences.

Automated hosting

As we use source control to hold and keep track of all our code and content, we can hook it up to our hosting - Netlify. When Forestry detects a content change, and Gitlab detects a code change, Netlify wakes up and gets all the new stuff and tells Gatsby to rebuild. We don’t have to do anything, this just works in the background.

Handling Imagery

Another benefit to using Netlify in particular, is its “Large Media” offering. As we have a lot of imagery, we don’t really want to store the (potentially) big files in our Git repository - this can increase the time the site takes to rebuild each time. Netlify Large Media uses “Git LFS” to keep track of these files as if they’re in our repository, but have them really sit somewhere else.

Netlify also allows “image transformation”, which is really cool. When we go get one of our images, we can explicitly specify the size of the image. So when you’re viewing our site on a high-res mobile screen, we can serve you a really detailed image, but if you’re loading it on an old monitor we can give you something more appropriate. If we know an image is going to display really small, like as a thumbnail, we can just use a really small image. This helps with page load speeds, and optimising the rendering of the site.

It can even work out the focal point of an image, and then crop it to that point!

Styling it up

Tailwind is a utility class CSS framework that lets us put the majority of our styling in the HTML itself, kind of like inline styling, but without the negatives. If you’ve ever built a site and found that you’re battling conflicts with other styling, or you struggle with naming things, then it is definitely worth a try!

A big benefit to having most of the styling logic on the HTML itself, is with dynamic styling. For example, on some of our pages we have a dark hero background. We can check the background colour, determine if it is dark, and then make the text white. You can of course do this with classes when working with normal CSS setups, but things like this are a lot easier to look after and maintain.

Ever make a big change to your HTML and styling and worry some users may only get one or the other, and your site could look temporarily broken? Well, because we’ve only technically made HTML adjustments without changing our stylesheet (CSS), users will always see the new stuff without any issues!


We’re still learning, but every time we try something new like this, we get that little bit better at it. This site is by no means perfect, and we don’t believe a site ever can be - they are in constant need of growth as users, industries, and requirements constantly change too.

Share this article
Don't miss a post, subscribe to our newsletter
Explore how to make websites better, opinion pieces, and more
Get started

Write us a brief for your new website

Introduce yourself

Introduce the main contact

About your business

Next step