Why we left Webflow and rebuilt our site as code

We didn't rebuild our website because it looked dated. We rebuilt it because the business underneath it had changed, and the old site was tuned for a company we no longer are. Idealogic has moved from broad, take-anything software outsourcing toward focused, AI-native engagements, and a site optimised for the old positioning was working against the new one. The rebuild was the moment we stopped patching around that gap. What follows is the honest version: the technical ceilings we hit, why the timing finally made sense, and the business reasons that mattered more than any of the code.

The stack we outgrew

Our history here is ordinary. We started on WordPress, moved to Webflow for the design control and the managed hosting, and got years of good service out of both. Neither was a mistake. They were the right call for a brochure site maintained by a small team. The trouble started when the site stopped being a brochure and turned into the largest content property we own, with services, industries, case studies, and a growing knowledge base all fighting for the same structure.

Webflow's ceilings are real once you push on technical SEO. Structured data can't bind to reference or multi-reference fields, so the relational schema that a content-heavy site needs ends up hand-authored in custom code embeds rather than living in a maintainable template. There's no server-level access, which means per-path response headers, X-Robots-Tag rules, and anything but the redirect logic the UI exposes are simply off the table. Canonical tags on paginated collections often have to be injected with client-side JavaScript, so the signal search engines lean on hardest isn't in the server-rendered HTML where it belongs. On a ten-page site none of this registers. Across a few hundred pages it becomes the shape of everything you're allowed to do.

Performance told the same story from a different angle. Webflow is quick out of the box, and that's genuinely to its credit. But "quick because the platform decided so" isn't the same as controlling how your site is built and shipped. We couldn't choose a rendering strategy per route, tune what JavaScript loaded where, or set our own performance budgets, because those levers belong to Webflow, not to us. Google publishes exactly which loading, interactivity, and stability signals it measures in Core Web Vitals, and we wanted to engineer against them directly rather than accept a good-enough default and hope.

Underneath both problems sat the one that decided it: ownership. You can design in Webflow, but you never fully own the runtime. Export gives you static HTML, not the CMS logic, the collections, or the relationships that make the site work. For a firm that sells software ownership to clients, running our own site on a host we couldn't take with us had started to feel like a contradiction we were paying to keep.

You can design a site on someone else's platform. You can't own it there. For a company that sells software ownership, that gap eventually stops being acceptable.

Why now: AI collapsed the cost of custom

The case against Webflow isn't new. What changed is the case for the alternative. For years the honest reason teams like ours reached for no-code was economics. A custom site meant writing the same scaffolding every time: routing, SEO tags, sitemaps, structured data, image pipelines, localisation, content modelling. That work was slow and dull, and it made custom hard to justify for a marketing site when a CMS got you live in a fraction of the time.

AI-assisted development moved that line. The boilerplate that used to eat the first weeks of a custom build is now generated and refined in an afternoon. Integration wiring that once argued in favour of a plugin ecosystem is quick to scaffold and easy to keep in code we own. Refactors that would have been too expensive to attempt are cheap enough to do routinely. The setup cost of a custom front-end fell far enough that the default flipped: custom first, no-code only where it genuinely adds net value.

The part worth being clear about is what didn't change. AI moved the economics, not the accountability. The architecture, the content model, the design system, and every decision about what was worth building stayed with our engineers. What we bought with AI wasn't a site that writes itself. It was permission to own our stack without the old cost penalty, and over a three-to-five-year horizon, staying on a managed host had quietly become the more expensive choice.

The site is a product, not a brochure

So we treated the rebuild as a product decision, not a redesign. The new site is a Next.js application where every article, page, and case study is a file in a git repository. No database, no admin UI, no extra service to keep alive. Content moves through the same pull requests, review, and version history as our code, which means the site is versioned, diffable, and revertable like everything else we build.

That sounds like an engineering preference, and it is, but the payoff is operational. A brochure site assumes the real work happens elsewhere, in decks and calls, and that publishing is a chore you batch. Treating the site as a product inverts that. Changing a service page, testing a new message, or shipping a case study is a small, safe, everyday act instead of a ticket that waits on a vendor or a hosting quirk. Content velocity stops being an aspiration and becomes a property of the system, and for a firm competing on how fast it can publish good thinking, that velocity is a real advantage rather than a nice-to-have.

There's a discipline cost, and we took it on purpose. A git-based, file-first system asks more of the people editing it than a polished CMS does. That trade is right for us because our content lives next to our code and our team is comfortable working in pull requests. It would be the wrong trade for a large non-technical editorial team, and we'd say so plainly. We built for how we actually work.

What actually changed: strategy, not styling

The technical reasons are the ones engineers like to talk about, but they aren't why the project got greenlit. The site changed because the strategy changed. We're repositioning from generic outsourcing, where the pitch was that we could build anything for anyone, toward specialised, AI-native work with a narrower and more serious buyer. That shift runs through the whole company strategy, and a site built to attract volume RFPs was pulling in the wrong direction.

Positioning like that has to show up in the architecture, not just the copy. So we re-organised the site around how buyers actually think rather than around our org chart: services mapped to concrete problems, industries where we have real depth, case studies structured to answer the questions a serious prospect asks before they commit, and a knowledge base carrying the ongoing argument about how AI-native delivery works. A prospect should be able to self-qualify long before a first call, so that every conversation starts closer to a yes and the wrong-fit inquiries filter themselves out earlier.

There was a quieter reason too, the kind you only admit in a post like this. We had started hesitating to send serious prospects to our own site, because it undermined the positioning we were making in the room. When a company stops linking to its own website in a sales conversation, that's not a design problem, it's a strategy problem wearing a design costume. Fixing it meant aligning the web work with the story we're actually telling, and putting that story where buyers, and increasingly the models they ask, can find it. If you want the fuller picture of the shift, our about page lays it out.

What's next

This post is the first real article on the new stack, which is fitting, because the whole point was to make publishing easy enough that the site keeps moving. The knowledge base will keep growing, the case studies will keep getting more specific about outcomes, and the architecture is built to absorb new services and industries without the bolt-on sprawl that eventually makes any site unnavigable. We'll write more of these build notes as we go, because the honest working details tend to be more useful than the polished summary. If a rebuild like this is on your own horizon, the same thinking is how we approach custom software for clients.