Why We Moved Our Site Off of Squarespace
Early this year, we launched a redesign of our website.
While we had a bevy of reasons for doing this, the impetus was our old Rails-built CMS was coming to end-of-life on an older, unsupported version of Rails. We faced a decision to update or try something new.
Decisions, Decisions
There was no real reason to build the site on a rails app; doing so in our mind just meant that we needed more back-end developer time to keep the site updated; a resource that is not always available for internal projects.
We discussed other CMS platforms that would not only be easy to switch to, but would also lower the bar for ongoing maintenance. It was then the notion of using Squarespace came up.
Trying Something New
The platform was gaining speed in support and usage. The UI for content updating seemed easy enough; anyone could make updates, not just those familiar in code. The team felt that with those benefits, we might have an opportunity to experiment more, make new landing pages and pivot off ideas quicker, faster; something that was not so easy on our old platform.
So in the fall of 2015, we started porting over content and we went live earlier this year.
Things we Loved About Squarespace
Off the bat, there were things we loved about Squarespace, like:
- Creating pages with the squarespace blocks was great and easy to use.
- Anyone could add content (when a content block is added into the page). No need to be a developer.
- Uploading photos worked well and was a no brainer.
- Images are well optimized and use fastly to stay cached through a CDN — with no setup for you.
When the Reality of Using Squarespace Hit
After a few short months, the honeymoon period was ending, and we started to feel the pain of trying to use a platform that caters to a one size fits all mantra. We were hitting a few too many roadblocks like the following:
- Not all areas are easily editable in Squarespace as we thought.
Adding a page, perhaps a title, or even a piece of copy and image isn’t bad. But as you start to design a site that has a specific style and function, or even a more complex layout, then you realize that most of that is created in custom code, and still requires a developer to build. - SSL is not supported.
It’s just not offered at this time - It is very complicated to set up a staging setup for your Squarespace site. This is important because:
* This makes making large design revisions nearly impossible.
* Staging is so useful for trying things out, entering data before it goes live, etc!
* It practically eliminates a QA process. - We’ve noticed some instability with Squarespace’s uptime.
It’s not horrible and it can be managed by using something like Amazon Cloudfront, but still not something you want to have to manage. - Buggy development environment with some frustrating quirks.
It’s worth noting that days after we began moving off Squarespace , an official local development server was released
We found that on a whole, these roadblocks were becoming harder to navigate. And we faced, yet another decision. To proceed our team had to decide to either stay with Squarespace — which mean devoting more time into a platform that we knew lacked the flexibility we needed and face the potential possibility of more issues we couldn’t foresee. Or, once again, try something new.
Final Decision
In the end we decided as a team — one year after making the first decision — we would be porting over our front-end and implement an out-of-the-box Ruby on Rails CMS called RefineryCMS. Making this decision allowed us to instantly gain access to useful things such as a secure SSL certificate and a staging site. And the CMS is still easy to use and manage.
So there you have it! While we think there are some advantages to Squarespace and enough workarounds to get us where we needed, we feel it’s probably better suited for a more simple/static site (with e-commerce and a blog).
Ps. We officially launched on Refinery last week, and our team is already busy with new designs and changes for the future.
Tags:learning business challenges cms
Originally published at blog.planetargon.com.
