Moving Our Website from HubSpot to Google Cloud, Built with AI
By rebuilding our website in our own Google Cloud environment with AI-assisted development, Crystalloids moved off an all-in-one SaaS platform to a site it owns outright: a design the marketing team changes itself, better performance on mobile, and a running cost that is a small fraction of the licence it replaced.
The Challenge
For years our own marketing ran on HubSpot: the website, our email and campaigns, our contact database and our social scheduling, all under a single licence. For a long time that worked well.
The website was where the limits started to show.
Template limitations. We were tied to the templates we had. Anything beyond them meant involving a developer and waiting for the work to be picked up, so design decisions were increasingly made around what the template made easy rather than what the page needed.
Mobile performance. Pages loaded more than they had to, and much of what they loaded was not ours to remove. Since Google looks at the mobile version first, that affected how the site was found as well as how it felt to use.
A licence that grew by purchase. Some capabilities required separate modules, the social media calendar and scheduling among them. More advanced campaign automation meant moving to a higher package. Better integration with sales sat behind another upgrade. Contact-based pricing meant that as our audience grew, so did the licence.
Each of those purchases made sense at the time. Together they meant the cost was set by how many things we wanted to do, rather than by how much we actually used.
What made a rebuild realistic was AI. The tools available today let a small team build what used to need a much larger one, and we wanted to see how far we could take that:
How far can we get with the tools available today?
So we set a plan and started building.
The Goal
For the website, the goal was narrow enough to state in a sentence: a site we design, build and change ourselves, running in our own Google Cloud environment.
In practice that meant:
- own the design and the front end outright
- move the pages that still earn their place, and leave the rest behind
- keep content management close to the way the marketing team actually works
- treat mobile as the primary experience rather than a secondary one
- make the switch without losing search visibility or traffic
- stop paying for capability by the module
The website was the first piece of a broader programme we call CrystalHub, which is replacing the whole platform one tool at a time. The CRM and the sales integrations follow, then email and campaign automation, then social scheduling.
Start Your Success Story with Crystalloids
Partner with Crystalloids and Google Cloud to bring your project to life.
The Solution
Deciding what to take with us
A migration is a good moment to question what still needs to be there.
We reviewed the site page by page and decided what to keep, what to rewrite and what to remove. Quite a few pages fell into the last category, simply because content tends to accumulate over time when nobody is responsible for taking it away.
Doing that before the rebuild meant we were not just moving the old site to a new platform. We were starting with a smaller, clearer version of it.
How a small team built it
The new site is entirely our own: a front end we wrote, content management assembled from open source components, running in our Google Cloud environment. One small team worked through the build, using open source where it already solved the problem and writing the pieces that are specific to us.
AI writes much of the implementation now, so the work that remains is deciding what a tool should do and making sure it is secure and fit for purpose. That part takes as long as it always did.
Reviewing the new site while the old one stayed live
The new site was built in its own environment, running alongside the existing one. Nothing was at risk while it took shape.
Marketing reviewed it page by page as it came together and handed findings back to development. That kept the loop short, so most problems were found while they were still small.
Before the switch we worked through a list of things that had to be right on the day: redirects, forms, the mobile version, and the basics search engines rely on. Only one version of the site is ever live, so the old and new sites never competed with each other.
The Result
Design and functionality we decide ourselves
We own the website and the way it works. If we want to change the design, adjust a workflow or add functionality, we can do it in our own environment without being limited by a template, a package or a product roadmap.
A site that is faster on mobile
The clearest improvement has been performance on a phone, because we now decide what each page loads. That matters for the people reading the site, and for how the site is found.
A smaller, more deliberate site
We came out of the migration with fewer pages than we went in with, and a clearer idea of what each of them is for. Publishing something new is now a decision about whether it is worth having rather than about what the template allows.
A very different cost model
Our marketing stack used to cost a five-figure sum every year, and it grew with each module we added. Today the running cost across the whole stack is a small fraction of that, and most of it is Google Cloud infrastructure and AI usage. We are no longer paying for modules we do not need, or for the size of our own contact database.
More ownership also means more responsibility
What we own, we also maintain. A SaaS platform takes care of infrastructure, updates and much of the operational work, and for organisations without engineering capacity that is usually a good reason to keep using one. In our case we already had the capability, we knew which functionality we actually used, and building it no longer takes the kind of team it once would have.
The rest of this series
- Moving the website — this story
- CRM and the sales integration with Exact Online
- Email marketing and campaign automation
- Blogging and social publishing
With HubSpot, we were tied to fixed templates, mobile speed was always a challenge, and making bigger changes required technical knowledge we did not always have available. Now we can shape the site around what we actually need, make changes faster and run it at a fraction of the cost.