The Sitesauce Story

May 01, 20204 min read

Today I'm launching Sitesauce, a one-click solution to generate static sites from practically any website. This is the story of why and how I built it.

The Why

It all started when I redesigned my website, around 10 months ago. I had been using Ghost as a headless CMS with a static site generator on the front, and got tired of maintaining two different codebases, porting themes over and syncing the content between the two sites. I moved towards a way simpler setup, using Ghost and a custom theme. Everything was way simpler and I could focus on writing.

But, after the first time my server went down while I was asleep, I started missing my old setup. While I had made the publishing process a lot simpler, it had costed me infinite scalability, 100% uptime, faster pages and a few other things I valued. After searching for ways to use static sites without going back to the old setup, I found Buster, a project that could crawl my Ghost site and generate a static version. The main problem is that it had been last updated six years ago, and I usually had to retry the build it three or four times to get it working, which meant I still had to manually manage the infrastructure every time I updated my content. Since I couldn't find a tool that did what I wanted, I set out to build one.

Building a prototype

The first thing I did was deciding how I wanted this tool to be used. I decided against integrating directly with the Netlify build process since I didn't want to be limited by their infrastructure, and started building it as a simple app that used their API to upload the generated sites instead. This API wasn't really documented at the time but with the help of swxy (who was working on Netlify at the time) and many hours of reverse-engineering their dashboard and trying out stuff, I managed to get it working.

However, that doesn't mean the entire prototype was working, as I had still not nailed the site generation part. I was initially trying to store the whole site in memory and only move it to the filesystem when compressing the site into a zip, and this proved to be not only highly inefficient but also a big blocker, since I often ran into memory issues that killed the process. However, after attending LaraconEU 2019 on Amsterdam and watching Kat's talk on performance optimizations, I finally managed to get it working.

Building an MVP

After finishing that first prototype (which required me to manually deploy my site using the command line), I started building a dashboard so I could actually use the application. On my last app I had built and launched a very rough version in a week, and I wanted to try doing the opposite this time, so I carefully designed each part of the interface from scratch, although in hindsight this took me way too much time (especially since I redesigned everything from scratch three times) and I should've just launched with a simpler interface.

design 1
design 2
design 3
HELP I CAN'T STOP REDESIGNING EVERYTHING (click to zoom)

Apart from design, the MVP also included creating and deploying sites (obviously) and proxying endpoints using Netlify Rewrites. Once all this was done, I gave access to a few friends to try it out, and they helped me squash lots of bugs (Duncan also tried crawling the BBC, without much success).

Moving to Vercel

At this point Guillermo (CEO of Vercel, which was still called ZEIT back then) contacted me and offered help in integrating with their platform. With the help of the Vercel team, I managed to highly optimize the build process, making it much faster and less prone to error. I also rewrote the core logic in Golang from PHP, which in addition to making it faster allowed me to run it directly in their infrastructure instead of running it on my server and uploading the resulting files. After Vercel announced their new pricing (which includes unlimited bandwidth for free),  I decided to go all in on Vercel and remove support for Netlify, since it was just adding a lot of unnecessary complexity. This also allowed me to make Sitesauce serverless, ensuring it can handle any amount of traffic while keeping costs down.

And finally, launch

I got carried away and kept adding and adding things to the MVP until it wasn't an MVP anymore. It's easy to find something to work on or something to improve each day, and so I fell in this trap of infinite iteration without launching to anyone but a few beta users (who were already using it in production). When I finally understood this, I decided to give myself a week to prepare everything and launch, to prevent getting caught up on small improvements again. A week later, Sitesauce is live on ProductHunt and I couldn't be more excited.

In summary

When I started Sitesauce, I never expected it to be more than a small tool that I used to get this blog into Netlify. I definitely didn't expect it to become the biggest thing I've ever worked on, taking eight months to build and a lot of challenges to overcome. I'm also really happy it has already helped some simplify their stack, save on servers and improve the experience of their visitors, and I hope many others can also benefit from it. If Sitesauce has piqued your interest, you can learn more and create an account on its website. You can also share it with your friends, coworkers or followers to help others find it. Thank you! 🥰

Enjoyed the article? Consider sharing it on Twitter so others can enjoy it too :)

Receive project updates, article drafts & thoughts on your inbox every saturday.

Subscribe