The Invisible Work

A client once asked me, genuinely and without malice, why building a Squarespace website took three weeks when "it's all drag and drop, isn't it?"

I laughed, because what else can you do? And then I explained. Not defensively, not resentfully, but honestly. Because the question isn't unreasonable. From the outside, what we do looks simple. Squarespace provides the templates, the blocks, the fonts, the colours. You drag things around. You type some text. You upload some images. You press publish. A child could do it.

Except a child couldn't, because what makes a professional Squarespace site different from a DIY Squarespace site isn't the platform. It's the thousand decisions that happen before, during, and after the dragging and dropping. Decisions that are invisible to anyone who isn't making them.

This article is about those decisions. Not to justify our fees (though it does), but because understanding the breadth of what goes into a well-built Squarespace site is the first step toward valuing it properly, both in how we charge for it and in how we talk about it.

Before a Single Block Is Placed

A three-week project might spend the first week without anything visible to show for it, which is alarming to clients who are expecting to see website progress and are instead getting questions, frameworks, and documents.

In that first week, a competent Squarespace designer is doing some version of the following.

Audience research. Who visits this site? What are they looking for? What devices do they use? What's their attention span? What questions do they have? What objections might prevent them from taking action? None of this shows up in the design directly, but all of it determines how the design is structured. A site for 25-year-old tech workers looks, reads, and flows differently from a site for 55-year-old retirees, even if the business is the same.

Content audit and strategy. What content exists? What content needs to be created? What content needs to be rewritten? What's the content hierarchy? Which pages are essential and which are nice-to-have? What's the ideal user journey from landing page to conversion? This is information architecture work, and it's the structural foundation that everything visual is built on.

Competitive analysis. What are the client's competitors doing? Not to copy them, but to understand the landscape. What's working in this industry? What conventions do visitors expect? Where are the opportunities to differentiate? A therapist's website exists in a context of other therapists' websites. Knowing what that context looks like helps you design something that stands out within it rather than in isolation from it.

Technical planning. What integrations does the client need? Booking system? Email marketing? CRM? Payment processing? Membership area? Each integration has implications for the platform choice, the plan level, the page structure, and the checkout flow. Discovering mid-project that the client needs Acuity scheduling but hasn't signed up for it, or that their email marketing tool doesn't integrate with Squarespace's forms, creates delays that eat into the timeline.

This is all invisible work. There's nothing to screenshot. Nothing to show in a progress update. But without it, the design phase is guesswork, and guesswork produces sites that look good but don't work.

The Design Decisions Nobody Sees

When the visual design phase begins, every choice is the result of reasoning that doesn't appear in the final product.

The font pairing wasn't "these look nice together." It was: the heading font has a high x-height that maintains legibility at smaller mobile sizes, its character width accommodates the client's typically long service names without wrapping awkwardly, and its personality matches the brand's positioning as professional but approachable. The body font was chosen for its screen rendering quality, its range of available weights, and its line-height characteristics at 16px.

The colour palette wasn't "these are pretty colours." It was: the primary colour meets WCAG AA contrast against both white and dark backgrounds, allowing it to be used for buttons and links in any context. The secondary colour provides sufficient visual distinction from the primary without clashing. The neutral tones were tested for readability at paragraph length, not just in colour swatches. The accent colour was checked against the most common forms of colour blindness.

The section padding wasn't "that looks about right." It was: 96px (12 units on an 8px grid) creates enough separation between sections to establish distinct content groups without making the page feel disconnected. This value was tested at mobile widths to ensure sections don't feel disproportionately spaced when the content compresses.

The heading size wasn't "big enough to look important." It was: based on a 1.25 type scale from a 16px base, giving a proportional relationship between all heading levels that maintains hierarchy without creating jarring size jumps. The H1 was tested with the client's actual page titles (not "Welcome to Our Website" but "Cognitive Behavioural Therapy for Anxiety and Depression in Adults") to ensure it doesn't wrap awkwardly on tablet screens.

None of this reasoning is visible in the final design. The client sees a font, a colour, a size, a space. They don't see the logic behind it. And that's fine, because the point of the reasoning isn't for the client to appreciate it. It's for the design to work.

The Build That Looks Like "Just Squarespace"

The build phase is where the "it's all drag and drop" perception comes from, because it is, in fact, a lot of dragging and dropping. But the decisions being made during the build are informed by everything that came before, and they include:

Source order planning. Placing blocks on the Fluid Engine grid in an order that produces a logical reading sequence when the layout collapses to mobile. This sometimes means the desktop layout isn't arranged in the most visually obvious way, because the mobile experience takes priority.

Image preparation. Not just resizing and compressing (though that's essential), but cropping to specific aspect ratios that work across breakpoints, choosing focal points that survive Squarespace's responsive cropping, and ensuring visual consistency across all images on a page (same lighting temperature, same depth of field, same stylistic approach).

Custom CSS. The code that closes the gap between what Squarespace's visual editor can do and what the design requires. Adjusted heading line heights, constrained text widths, enhanced focus indicators, responsive tweaks for widths between Squarespace's built-in breakpoints, custom button styles, improved form layouts. This code is invisible to the client but visible to every visitor.

SEO configuration. Meta titles and descriptions for every page, written with keyword intent and click-through optimisation. Alt text for every image. Proper heading hierarchy. URL slugs cleaned up. 301 redirects set up for any old URLs that need to point to new locations. Schema markup injected where appropriate.

Cross-device testing. Not a quick check on one phone. Systematic testing across iPhone, Android, iPad, laptop, and widescreen. At every width, checking: does the layout work? Is the text readable? Are the touch targets large enough? Does the spacing feel right? Do the images load properly? Does the navigation function?

After Launch: The Work That Never Ends

The site is live. The client is happy. The project is "done." Except it isn't, because a website is a living thing that degrades without maintenance.

Over the following months and years, a conscientious designer is monitoring performance (have Core Web Vitals degraded since launch?), checking for broken links (that restaurant the client linked to has closed), verifying third-party integrations still work (the booking widget had a URL change), reviewing the client's content additions for design consistency, updating custom CSS if Squarespace platform updates change selector names, and advising on content strategy, new features, and platform changes.

This ongoing work is often uncompensated, which is a business problem we need to solve as an industry. But compensated or not, it's work that directly affects the quality and performance of the site over time. A site without maintenance doesn't stay at launch quality. It declines. Slowly, invisibly, and inevitably.

Why This Matters

Talking about the invisible work isn't self-indulgence. It's professional survival.

When a client says "it's all drag and drop," they're not being dismissive. They genuinely don't understand why what we do costs what it costs. And if we can't articulate the value clearly, can we blame them?

The answer isn't to overwhelm clients with technical details. It's to be honest about the process. "The three-week timeline includes research into your audience and competitors, content planning and strategy, the visual design itself, the build and customisation, thorough testing across devices, and SEO setup. The drag-and-drop part is about 20% of the project. The other 80% is the thinking that makes the drag-and-drop part effective."

That's not defensive. It's factual. And it changes the conversation from "why does this cost so much?" to "I see why this is valuable."

Every article in this series, from CSS specificity to accessibility to colour theory to discovery calls, represents a strand of knowledge that informs the invisible decisions behind every professional Squarespace site. Individually, each strand is interesting. Together, they're the difference between a website and a website that works.

That difference is what we sell. Not the drag and drop. The thousand invisible decisions that make the drag and drop matter.