My fundamental difference
Those platforms are made to build almost anything for almost anyone. That sounds useful. For a local business, I think it is the problem: too much machinery, too little ownership, and another rebuild waiting for you when the platform no longer fits.
This is the current service position. Older Squarespace projects in the portfolio are labelled as historical work, and the rescue and migration offer helps businesses move from legacy platforms to today’s static stack.
My position
A business owner thinks they are buying a website. Too often they are renting access to a system that the website cannot leave. The monthly bill is only part of the price; the rest is paid in speed, complexity, dependence, and future migration work.
A builder has to support stores, memberships, scheduling, animations, apps, dashboards, theme systems, and endless configuration. A local service website still inherits the architecture built to serve all of that possibility.
The feature sold to the owner—the dashboard—is also the reason the site needs a platform, an application stack, or a database. Visitors pay the architectural cost for an editor they will never use.
The words may export. The working design, templates, integrations, behaviour, and deployment usually do not move as one clean website. The next platform becomes another migration project.
More scripts affect speed and privacy. More plugins, themes, accounts, dashboards, and server layers increase the compatibility and security surface that someone has to maintain.
01 — The architectural difference
Purpose-built static
How I build
General-purpose platforms
Squarespace, Wix, WordPress
How a page is delivered
Pre-built HTML served from an edge network
A CMS or platform stack, usually helped by layers of caching
Browser code
No JavaScript by default; add only what earns its place
Platform, theme, plugin, app, and integration code can accumulate
Where the website lives
A complete source repository you can copy and deploy elsewhere
A proprietary platform or a database, theme, plugin, and hosting stack
Leaving
Move the same built site to another static host
Export what is available, then commonly rebuild the working site
Maintenance surface
No public CMS, plugin catalogue, or database required
More accounts, application layers, updates, and dependencies
Hosting
Portable across static hosts; free tiers are often enough
Subscription hosting or a managed server is part of the deal
Editing
Files by default; connect an editor only when it is useful
A visual editor is built in and permanently coupled to the site
Search foundations
Designed around the actual business, pages, services, and locations
Platform defaults, templates, and plugins still need strategy
Individual implementations vary. A carefully cached WordPress site can be fast, and a badly built static site can be slow. I choose the architecture that makes the fast, portable, low-maintenance result the default rather than an optimisation project.
02 — Speed
An uncached WordPress request can involve PHP, a database, a theme, plugin hooks, and external services before the browser receives a page. Good hosting and full-page caching can hide much of that work—which proves the point: the fastest version is the one that behaves more like a static site.
Squarespace and Wix operate their own CDNs and caches, but every site still inherits decisions made for a mass-market platform: its rendering model, asset pipeline, editor, integrations, and client-side code. You can optimise inside the box; you cannot remove the box.
I start with the finished HTML. Astro renders the website before deployment and adds no client JavaScript by default. Images are prepared during the build. The host serves simple files from the edge. There is far less work left for the visitor's phone to do.
The ordinary page already exists before the visitor asks for it.
JavaScript is added for a real interaction, not because the platform needs it.
The codebase contains the design and features this business actually uses.
Performance is the starting architecture, not a collection of fixes layered on later.
03 — Ownership and portability
Your content may legally belong to you while the working website remains inseparable from its platform, theme, plugins, or database. Real ownership means possessing the complete, useful thing—not a partial export that needs another website built around it.
Squarespace
Squarespace says only certain content exports, while style settings, custom CSS, many page types, and platform-dependent features do not.
Read Squarespace's export guideWix
Wix says a Wix site cannot use another host because its SaaS architecture relies on Wix's proprietary technology and services.
Read Wix's hosting explanationWordPress
WordPress is open source and its content can be exported, but its own performance guide points to hosting, databases, caching, themes, plugins, and updates as performance factors.
Read WordPress's performance guideA static website moves as a website. Copy the repository, choose another host, deploy the same files. That is the standard I mean when I say you own it.
04 — Security and maintenance
No website is magically invulnerable. Domains, hosting accounts, forms, and third-party services still need to be secured. But a static marketing site does not require a public admin login, live content database, PHP runtime, theme updater, or plugin catalogue just to show people your services.
That removes entire classes of routine maintenance and attack surface. It also removes the familiar WordPress cycle of core updates, plugin updates, theme compatibility checks, cache configuration, and hoping one vendor's change does not break another vendor's code.
There is no administration endpoint attached to the public site unless the project genuinely needs one.
A database outage or slow query cannot stop a pre-built page from being served.
Forms, analytics, and other capabilities are deliberate integrations rather than an open-ended pile of plugins.
Fewer layers need patching, monitoring, caching, debugging, and paying for every month.
05 — The local business deal
A local business website has a clear job: explain what you do, establish trust, get found in the right searches, and turn the right visitor into an enquiry, booking, or sale. A drag-and-drop dashboard is not one of your customer's requirements.
Static architecture puts the money and attention into the work that produces a return—strategy, content, design, local search, structured data, and conversion—instead of a permanent platform subscription and the technical baggage that comes with it. Free-tier static hosting is a useful bonus. Ownership and performance are the real deal.
06 — The honest trade-off
If you need a social network, a real-time member dashboard, or a complex transactional application, you need application infrastructure. If a team publishes constantly, I can connect a headless content editor. If a page needs a booking widget, calculator, gallery, or search, I add that interaction deliberately.
But most local business websites are content, navigation, images, and a way to make contact. Wrapping that in a permanent general-purpose platform is solving the wrong problem. I build the simpler, faster thing because it is the better business decision.
I build fast, static websites that belong to your business, help it get found, and give customers a better experience.