The rocket that proves our point: why we moved our website off HubSpot
For months we have been making the same argument in different forms, whether we were writing about the Balancer and the danger of tethering yourself to a single AI provider, or our pieces on EU sovereignty and the risks of running sensitive data on infrastructure you cannot ultimately control. The thread running through all of it is deceptively simple: you should own what you depend on, and you should be able to leave if the ground shifts beneath you. There was, however, one conspicuous place where we had not taken our own advice. Our own website.
01 · The hypocrisy we couldn't ignore
It ran on HubSpot, as many company sites do, and we should be clear that HubSpot is a genuinely capable platform; this is not a hit piece or a complaint about the product itself. But it is, in miniature, precisely the kind of rented foundation we keep warning clients about. Your pages, your forms, your design logic, and a non-trivial slice of your customer-facing experience all live inside someone else's system, shaped by what that system permits, priced according to terms you do not set, and quietly difficult to walk away from once every form, tracking pixel, and landing page is wired into the machine. It is convenient at the start, and only reveals how hard it is to leave once you have settled in. We had written almost those exact words about cloud providers and AI vendors, all while our own front door sat on land we did not control.
So we moved it.
02 · We walk the path first
This is the same discipline we apply in our sovereignty work: before we recommend a path to a client, we walk it ourselves. Once we had built our own Business Suite, moving the website onto it was the obvious next step rather than a leap into the unknown.
Here is where we must be honest about something more uncomfortable than a HubSpot bill. We are not innocent bystanders in the platform economy. When we integrate a client into our Business Suite, we are creating dependency; the software works precisely because it embeds itself into their operations and becomes difficult to casually replace. In that narrow sense, we are doing exactly what HubSpot does. We are moving people onto our platform, and we are not pretending they can unplug overnight without friction.
The difference is not that we have eliminated gravity; it is that we have chosen to anchor our clients to something they ultimately steer. HubSpot's roadmap serves HubSpot's shareholders and its mass-market average; your specific workflow is secondary. When you build on our stack, the automation, the logic, and the data architecture are built for your operations, using standard coding patterns and transparent integrations that you can inspect, export, and redirect if you ever need to.
Dependency is inevitable when a tool is doing its job well; captivity is a choice made by the vendor.
We build for the former and actively avoid the latter.
03 · The migration was the message
The honest surprise was how little drama there was. We had braced for the kind of migration tax that convinces companies to kick these projects down the road for years, and it simply never arrived. Because we were moving only the website (not our CRM data, not our marketing automation, not our back-office workflows), the scope was disciplined, and because we control the layer underneath, there was no platform fighting us, no export limits to work around, and no waiting on someone else's roadmap.
The entire migration took hours rather than the days we had budgeted.
That speed was not luck; it was the result of the same automation discipline and pattern-based development we apply to client work. Our coding practices are built on strong automation and reusable architectural patterns, which means we spend less time reinventing fundamentals and more time producing high-quality, specific output. We did it for ourselves during this migration, and we do it for our customers every day, including those who don't have an in-house team to build it.
04 · The rocket we could finally build
Years ago, when Gysho was new, we sketched a design idea we loved and could not execute: a small rocket that travels with you as you move through the site, a companion along the journey. On the tools we had then, it remained a sketch. On our own stack, we finally built it. There is now a small rocket that follows you across the site, and yes, it is a deliberate nod to the version of us that drew it years ago and had to let it go for lack of control over the ground we were building on.
It is a tiny thing, and it is also the entire argument in miniature. When you stop renting the ground you build on, you stop trimming your ideas to fit someone else's platform constraints.
The rocket exists because the site is finally ours.
05 · The question every company should ask
The principle scales up and down. Whether you are evaluating the AI models you build on, the infrastructure your data lives in, or the website at the front of your business, the question is the same: do you own what you depend on, and could you leave if you had to?
Most companies have at least one critical system running on a platform they could not walk away from without months of pain. If that is you, here is a quick audit:
- Could you export all your content and customer data in one day?
- If your platform doubled its prices tomorrow, could you leave within a quarter?
- Are there features you need that your platform refuses to build because they do not serve its average user?
If any answer is no, it is time to talk.
06 · Ready to start the conversation?
We have walked this path ourselves, and we have done it using the same automated, pattern-driven approach that lets us deliver serious work in less time without sacrificing quality. We know where the hidden complexities are, and we know what a successful migration looks like because we have done it, starting with our own front door.
If you visit the site while you think it over, the rocket will be there with you. And if you are ready to talk about your own stack, here is how to reach us.