I’ve recently migrated from Squarespace, taking the deep-dive, developing my own website from the ground up. My goal now is to document my thoughts and process and retrospect on the decisions I’ve made. This post is the first of a series documenting the rework.

Why I’m Moving off Squarespace

Squarespace is Expensive

At the time of writing this, Squarespace has pricing tiers and pre-paying for a year incurs a 30% discount. The cheapest tier, “Personal”, costs $23 monthly or $192 annually. This plan has some painful limitations, which I will cover in the next section. The next tier, “Business” includes things such as custom Javascript, CSS and some e-commerce capabilities. This tier costs $33 monthly or $276 annually. One benefit of this type of pricing model is that I am paying for a live website. I do not get charged based on individual page loads, network bandwidth, nor any other parts of Squarespace’s infrastructure. This can be nice for high-traffic websites or websites that are serving many large assets like pictures or videos.

S3 Cost

In comparison, hosting a high-traffic website on AWS S3 will incur charges for all S3 operations (e.g., GET, LIST) and for egress. This can become costly if, for example, thousands of users download a large MP3 file from my site over a short period of time. This may not seem a likely risk, but it can happen. Fortunately or not, my website does not receive a lot of traffic — maybe about 100 views a week at best. My website does not have too many large assets, either. Some of my visual art can be up to 5 MB per image, but with compression and WebP encoding, bandwidth is not a considerable concern. This being said, my current website comes in at around 150 MB total, with more than 96% from images.

Approximating the cost of my web traffic, if hosted on S3, is relatively easy. Assuming:

• 150 MB for the whole website
• 100 total files (HTML, CSS, images, fonts, etc.)
• 100 users a week
• each user clicks every webpage and loads every file

That becomes approximately 40,000 GET operations and 60 GB of egress traffic. If hosted directly from an S3 bucket, the monthly cost breakdown is:

• $0.023 for storage
• $0.016 for GET operations
• $5.40 for data egress

Which makes a lot more sense for me. Cheaper alternatives to S3 hosting exist, such as Backblaze B2 and DigitalOcean Spaces, and using a CDN to name a few. But I’ll cover these details in a later section.

Squarespace is limited

Or more accurately, Squarespace is limiting.

Customization

My biggest gripe, and the straw that broke the camel’s back, is that custom CSS and Javascript are premium features that require, at minimum, a “Business” tier plan. I write technical blog posts and I need to share code snippets. Syntax hi-lighting, formatting, and having a “copy” button on a code snippet are essential! But are they worth $84 a year? And that’s not $84 a year for these features, it is $84 a year for the ability to implement things myself.

Website / Bundle Size

Squarespace looks pretty nice, but at a cost. My current website, hosted on the platform, does not have nearly enough optimization. I have a (nearly) static website. When I open the site, I should not download large Javascript bundles. Images should be optimized and resized. The website should be lean and small! But it’s not. Images are served at original size and resized client-side. Ok, maybe that one is on me, but I think there has to be a better approach. I would rather not download all my assets, resize them, and upload through a UI. It’s just not productive.

Writing

Squarespace is a painful platform for writing, and doubly so for technical writing. Most of my writing is done in Ulysses or in Vim / NeoVim on markdown files. I like markdown, it’s great for technical (and non) writing. But too often I find myself copy-pasting sections of my writing into Squarespace, inserting links or code blocks, and it is tedium.

Exercising my UI Muscles

In my professional life, I have mostly existed in the backend or working on infrastructure. But I’ve always dabbled in a little frontend work, albeit avoiding any HTML and CSS as much as possible. However, it’s difficult to be a good backend web developer while being ignorant of frontend patterns, concerns, and developments. I’d rather fight the uphill battle in making my own site than remain unhappy and tolerant.

There’s probably something to be said about the quality of one’s own labor.

This Series

I plan to follow this up with a deep dive into technical aspects of my website rework. As of writing, I envision the following posts:

• Making the Website with Parcel.js
• Packaging and Tooling with Nix
• Infrastructure and Costs with AWS