As late as December 30th 2025, Hopsworks’s website contained well over 1,000 pages. It was a mix of blogs, dictionary entries, videos, and various content types – but mostly, it was a pile of legacy pages and landing pages.
As of today, February 2026, thanks to tools like Claude Code, we have completely shifted our approach. Within a week, we have cut our page count in half, moved away from our legacy hosting and CMS, and essentially refactored the whole site. The result is a platform that is:
- More SEO and AEO (agentic engine optimisation) friendly
- Faster to load
- Easier to update
- Cheaper to maintain (with less vendor lock-in and technical debt)
Back in 2018, we chose Webflow as our hosting and CMS solution. Quite honestly, it proved to be exactly what we needed at the time. It was easy for non-technical users to maintain and made adding content easy. But, like everything else, this convenience came at a cost. Over time, we accumulated layers of legacy content and structural debt. We became highly dependent on their platform, meaning our entire library was hosted on their infrastructure with very little flexibility to move out.
Shifting to Code-First
A few of us on the team grew to be avid – if not overly enthusiastic – users of Claude Code, not unlike a large portion of your favourite social media’s front-page I am sure. And as our internal usage grew over the course of the year, a new paradigm emerged. As product owners, and marketeers, we realized we no longer wanted to spend time “moving boxes” in a UI. We wanted to alter and shape the code directly to output what we needed, often based on existing content.
And so we realised over time that the handy low-code/UI-driven approach of Webflow became not quite so handy anymore. We wanted to change the code directly, not just tweak a component here and there. Dragging and dropping had simply become a drag that we wanted to drop (pun intended).
The Migration
We made the jump in a single go. We pulled the whole website and its content library, asked Claude to parse it, created a skeleton using an open-source headless CMS, and migrated all content to Markdown We then re-created the frontend, partly based on the same UI library we use for our own software platform.
Two hours later, a functional, viable draft containing the entire content of the old website was online.
It took just two hours to rebuild, re-architect, and redeploy a functional website based on the 1,000 pages of the old one. It took a few more hours to set up proper redirects, SEO, polishes and debugs. It was a cathartic – albeit scary – experiment to think that we were about to essentially erase six years of a relationship with a toolset in a single afternoon.
A new and unexpected benefit of this shift is the cultural change within the team. Moving even less technical team members toward a technical stack consisting of version control, IDEs, and CLIs forces them to engage with the tools that our engineering team uses every day.
This lowers the “understanding gap” between teams. Everyone is now speaking a more common language. While the depth of knowledge may differ, it provides a starting point for collaboration.
Some of the benefits we actually found can be summed up in this table:
| Webflow / SaaS | Code-First (CC-Website) | |
|---|---|---|
| Editing | Symbol (components) or page level | Global Replacements & Refactors |
| Versioning | Backup system, full website only | Github |
| Hosting | Built-in | Self-Managed |
| Lock-in | Almost total; content & code | None (lives locally or in repo) |
| New users onboarding | Weeks | Hours (or instant for devs) |
| Empower Engineers | Impossible | Easy (Upload Markdown to repo) |
The 80% Traffic Drop
Gaining full control over our code also meant we could no longer blame anyone when things looked wrong. And things looked very wrong. It did seem like it didn’t work, at all, a massive loss of 80% of the traffic was registering on all analytics.
Quite honestly, it was a terrible couple of weeks wondering if that was just vibe coded slop, missing content during the migration, Google penalising us, SEO schemas not being set properly, redirects not working; you name it we thought about it all day every day. The inherent nature of traffic taking time to be impacted by changes also meant; we had to be sort of patient with our assumptions.
Until a few days ago, when we had a realization; when we rebuilt the website, we thought also to rebuild the analytics and how we were tracking users.
It turns out, with our previous setup. We were tracking more visitors than we intended to. What happened is that we were not storing user information if they did not accept our terms, and so they were anonymous to us, but there were no such mechanics for Google Analytics so Google tracked them anyway.
Now, with the website being rebuilt. We followed best practices; accepting cookies would directly impact whether the website would be passing user information to Google and other third party analytical tools as well as ourselves. And so, it turns out, lots of users do not want to accept cookies, and it turns out, we do not send their information to Google; we do however, have set an internal cookieless analytical tool (self-hosted in EU & no IP collection) to indeed see the traffic on our site.
So we did not lose 80% of traffic. Sorry. We did not in fact lose much traffic at all (there was a drop post-migration that now seems to recover organically). We vibe coded best practices in passing, forgot about it, scared ourselves, spent a few weeks thinking that our whole plan was a terrible idea and that we should admit defeat. Turns out it is all good.
SaaS and Commoditization
Who are the next targets?
Well, any other tools that have added debt, cost, and systemic weight to the organization with obvious ones like – CRMs, marketing automation, and such. If everything is just a table somewhere, and if everything can be created bespoke in a few hours, why pay tens of thousands of euros for it? We are doing the work of setting it up, managing the data, cleaning and integration with our ecosystem anyways. The value seems to be diminishing by the hour.
Does this imply that every software company must take a hard look at their value proposition and ask themselves: “Are we at risk of becoming commodified by tooling such as Claude?”…
The answer is likely; yes.
We are ourselves a software company; we are builders, and we know that we also would either benefit or suffer from the very same question; a simple prompt such as “Please create my own feature store and MLOps platform,” where a few hours later, the organization has its own bespoke tool. So where to draw the line?
It sits at the runtime/engine/core. What gets commoditised is the setup, the glue, the configuration and orchestration layers; things you can prompt into existence. What doesn’t is the core: the API, the execution engine, the years of production edge-cases baked into a platform. You can prompt your way into connecting a feature store, configuring it, deploying pipelines on top of it; but the platform that runs them reliably at scale is not a weekend project.
So, for us, this is exactly where we are going. We aim to apply that same lesson to our own very own software platform, making it something users can operate on and build upon at the speed they can prompt. This must be the new motto for startups. Business as usual is but a prompt away from being replaced.
P.S. While writing this article, the following message was sent to a colleague:
The table you see above is now actual markdown, not an image. One down, a few more to go.