Squarespace is a good product and, for a large share of sites, the correct one. The useful question is narrower: how much control do you need over the markup, the server side and your own content, and is renting the platform for as long as the site exists a fair trade? Here is where that line usually falls, including the cases where it falls on Squarespace's side.
Where Squarespace is genuinely the right answer
Squarespace solves a real problem. It turns a design system, hosting, SSL, a CDN, an image pipeline and a commerce backend into one subscription that a non-technical person can run alone. If your site is a portfolio, a restaurant, a studio, a personal brand or a small catalogue, and its job is to look credible and collect enquiries, a well set up Squarespace site does that competently. Nobody has to patch a server, renew a certificate, apply a CMS security update or work out who controls the deployment pipeline after a contractor stops answering email. That burden is real, and the platform absorbs it.
It also fails safely. A Squarespace site does not go down because a plugin conflicted with a core update, which is still the most common way a self-hosted WordPress install breaks. Responsive image sizing and lazy loading are handled for you. The URL mapping tool issues real 301s rather than client-side redirects. Titles, meta descriptions and slugs are editable, canonical tags are emitted, and a sitemap is generated. The robots file is generated for you too, which is fine right up until the day you need to change it.
If nobody on your side wants to touch code and the website is not the product, staying where you are is a defensible engineering decision, not a compromise. We say so when it is true, including to people who email us hoping to hear the opposite.
What you cannot change: the markup Squarespace emits
The limit people hit is not that the templates look bad. They look good. It is that in 7.1 every site runs on one underlying template with style presets on top, so you compose from a fixed set of blocks and sections. You control spacing, type, colour and arrangement. You do not control the DOM those blocks produce, and that shows up in four places.
Heading structure: block editors emit heading levels that match visual size rather than document hierarchy, so fixing an outline means fighting the editor instead of writing markup. Structured data: anything beyond the platform defaults goes in through code injection as a hand-maintained JSON-LD script, which then has to stay in sync with content someone else edits in a WYSIWYG. Front-end payload: you inherit the platform's JavaScript and its font loading strategy. You can defer your own scripts; you cannot remove theirs, and when a Largest Contentful Paint problem starts inside a section's own render path, the only fix available to you is a different section. Response headers: you do not set them, so a Content Security Policy, custom cache rules or security headers are not on the table.
Custom CSS and code injection are available from the Business plan upward at the time of writing, and they cover a great deal. What they do not give you is the render pipeline, which is exactly what technical SEO work eventually needs.
Nothing of yours runs on their servers
The second wall is server-side. Squarespace runs no code of yours at request time: no API route, no webhook receiver, no scheduled job, no logic before the HTML is sent. Everything custom happens in the browser after their page has loaded, which is fine for a widget and useless for anything that has to be correct before render.
This is where projects stall in practice. A form that must POST into a CRM with field mapping and deduplication. Pricing that depends on the signed-in customer. A stock feed from an ERP. A booking flow reading real availability. A generated invoice PDF. A client portal. Form submissions route to a limited set of destinations, and the commerce APIs for orders, products and inventory sit behind the higher commerce tier, so read the current plan comparison before you design around them. The usual workaround is to chain a third-party automation tool, which means another subscription, another failure point and another company holding your customer data.
There is also no staging environment and no version history for injected code. You edit the production site, and rolling back means remembering what was there before. On a brochure site that is a non-issue. On a site three people edit in the same week, it is the thing that eventually costs somebody an afternoon.
On a closed platform you rent, and the export is partial
Ownership is what people discover late. The subscription is not a build cost you amortise over five years, it is rent for as long as the site exists. Stop paying and the site stops serving. That is the deal on every closed platform, and it deserves to be stated plainly rather than treated as a scandal. What we build works the other way round: you own the code, the accounts and the domain name, and there is no subscription to us keeping any of it alive.
The export is where it bites. Squarespace produces a WordPress-format XML file whose documented scope is partial: pages, one blog, text and image content. Product pages, event pages, album pages, custom CSS, code injection and your style settings do not come with you. Your domain transfers out normally once past the ICANN lock. Your design does not transfer at all, because the design is the platform.
So a migration is never an export followed by an import. It is: inventory every live URL, decide which ones still deserve to exist, rebuild one template per content type, move and rename media, rebuild the redirect map so link equity survives, rebuild forms and their destinations, then re-point DNS with the TTL lowered in advance and a rollback plan written down. Effort scales with the number of distinct page types and integrations, not with the number of pages.
When to stay put, and when not to hire us
Do not migrate for the sake of migrating. If your site is a brochure with a contact form, no integrations, no multilingual requirement and one marketer publishing twice a month, a custom build buys you very little and costs you the thing you already have: anyone non-technical can change anything, immediately, without asking a developer. That is worth more than a better Lighthouse score on a site nobody is fighting to rank.
Do not hire us if you need a supplier who joins calls. We work in writing only, and if your organisation makes its decisions in meetings we will be a poor fit and both sides will know it by week three. Do not hire us if you need someone in your office, because we do not travel. Do not hire us if nobody on your side can write content or reach a decision in writing within a few days: asynchronous work fails when one side goes quiet, not when it goes slow.
Do not hire us if the honest answer is that the site is not commercially important. If it drives no revenue and nobody opens the analytics, keep the subscription and put the money where the revenue is. We would rather write that in the first reply than three weeks in. And if you are staying on Squarespace mainly because you fear being locked in to a developer, say so in your first email. That fear is legitimate, and it changes what we would build, not whether we would.
How two people in Dijon work with a client eight time zones away
We are two people. Robin Monteiro writes the code (Next.js, React, the data layer) and Florian Loppion handles the marketing side. We work from 9 rue Jean-Jacques Rousseau in Dijon, France, on Central European Time, and that is the only office there is. We are a small French team and will not pretend otherwise. For an international client that cuts both ways, so here is the honest version.
What you get: the people answering your email are the people doing the work, with no account manager turning your request into a ticket and the answer back into an email. Everything happens in writing, by email, with a reply within 24 business hours, which takes the time zone out of the equation. Nobody in California sits on a status call at 3am, because there is no status call. A question written at the end of a European day is answered and waiting when the thread is opened in Bengaluru or Boston.
What you do differently: batch your questions instead of pinging. Front-load context, meaning the URL, what you expected, what happened and a screenshot, because there is no call in which to clarify. Approve in writing. Expect specs and decisions as searchable text, which pays off nine months later when someone asks why a field was made optional and the answer sits in a thread rather than in somebody's memory.
Work we can point to: Chouchou Ribeyre, Au Petit Detail, LB Athletic, Mediavocats, Vectosolve, all French SMEs.
