From Squarespace to a custom system: when a website is no longer enough.

The original Squarespace site had four basic pages: Home, Services, About, and Contact. It presented the organisation clearly and professionally. For an early-stage association, that was the right priority.

But over time I noticed a growing gap. Events were managed outside the site. Journal content was distributed elsewhere. Member communication happened through messages and manual lists. The website worked like a storefront, while the real operations happened outside it.

The old site was static, one-way, and closed. Content was written into pages and then stayed there. Visitors could read, but they could not really do anything. Even the Login item in the navigation was mostly symbolic. It did not point into a real working system.

The job of the website changed from "help people understand who we are" to "support how the organisation actually runs." That meant the website was no longer just a communication surface. It needed to become part of the operating system.

At that point, the question was no longer whether Squarespace looked good enough. The question was whether it could support the work the organisation now needed to do.

In Jobs-to-be-Done terms, the old website had really only been hired to do one job: help visitors form a first impression of the association. Squarespace did that job very well. But once operations became real, the daily workflows were happening outside the site, which is a strong signal that the tool and the actual work have drifted apart.

I did evaluate whether Squarespace could be stretched further. It had membership features, blog modules, and forms. But the conclusion was still no. The most important reason was not that it lacked one specific feature. The real issue was structural incompatibility with the product direction I needed.

By that point I already knew the organisation would need a native iOS app so members could participate more directly on mobile. If data stayed trapped inside Squarespace without proper database control or custom APIs, it could not become part of a broader system. That is not a missing feature. It is a platform-boundary problem.

AI changed the build-vs-buy equation because it lowered the implementation threshold enough that a single product manager could realistically take on a much larger part of the system design and build process.

The old site mostly served anonymous visitors. The new system had to support multiple user types: visitors, members, content operators, event managers, and administrators. Once those users appear, the product boundary changes completely.

A static site builder can support communication very well. It is much weaker when you need permissions, workflows, records, reusable content structures, and shared backend logic.

That user-model shift is the heart of the product change. The old website mainly served information consumers. The new system also had to serve information producers and system managers. As soon as those users enter the map, the information architecture, permission structure, and data model all need to be redesigned.

In practical terms, this meant moving from "four pages with static text and images" to "structured data models rendered across multiple surfaces." Events became real records with titles, times, posters, and registration states. Journal content became structured entries rather than PDFs passed around elsewhere. Login became the front door to an actual membership system, not just a symbolic navigation item.

This move was not just a "migrate the website" task. It was a redefinition of the product itself. The login link on the old site was mostly symbolic. In the new system, login became a real entry point into membership, permissions, records, and participation.

The difference was not a nicer interface. It was the difference between showing that an organisation exists and giving that organisation digital infrastructure that actually helps it run.

That is also why I see the redesign as a positioning change, not just a technical rebuild. The old product's value was "help people understand who we are." The new product's value was "let the organisation operate inside a real system."

AI did not decide the product model. I defined the roles, data relationships, workflow priorities, and platform direction. AI helped translate those decisions into working technical implementation more quickly across data models, APIs, and interface structure.

That distinction matters. AI lowered the implementation barrier, but the product design work still came first. The better I could define the system, the more useful AI became.

One useful example is that the old repeated images on the Squarespace site were not "fixed" in the new system as a visual problem. They disappeared because the content model changed. Real event posters, journal covers, and updated content naturally filled the space. That change came from product structure, not from visual patching.

The old website served its phase well. The rebuild became necessary when the organisation reached the point where a brochure was no longer enough. That is a product turning point many teams recognise too late. By then, the real work is already happening somewhere else.

What stayed with me most is that the old Login item was once just a symbol with nothing behind it. Now it is the entrance to a working system with accounts, permissions, records, backend workflows, and shared data. That distance is the distance between a site that announces an organisation and a system that actually supports it.