How a rebuilt front end let a contact center AI company's own team keep building

A company that grew faster than its front end could follow

The company sells AI performance enablement to contact center teams, and most of its growth ran through the marketing site, with search as the main channel.

It had grown quickly and the front end had not kept pace. Several class systems overlapped, added at different points as the site expanded, none of them finished. A site in that state does not announce itself: it looks fine, and it fails quietly at the twentieth page. There is no predictable place for a new class, no way to know whether changing one affects something else, and no way to tell which of three similar classes is the live one.

So what was needed was not a redesign. The design was not the problem.

What it was actually costing them

The marketing team knew what it wanted to publish. The search strategy was good and already running. Neither of those was the constraint.

The constraint was that every new page had to be argued into existence. Correct heading order had to be requested rather than inherited, so a search specialist's time went into structural corrections instead of into the next page. Output fell to whatever survived the friction.

This is the part most companies misdiagnose. They look at a site that is underperforming, conclude it needs to look better, and buy a redesign. The redesign resets the appearance and leaves the bottleneck exactly where it was.

What Max Performance changed

1. One naming system in place of several

The front end was rebuilt on Client-First, the Finsweet naming and structure methodology that is the de facto standard for professional Webflow projects. Max Performance is a Webflow Certified Partner and builds every project this way.

The whole thing turns on one distinction. A class is either a utility class, reusable across the project and named with dashes, or a custom class, specific to one component and named with an underscore that groups it into a virtual folder. text-size-large is reusable anywhere. pricing_feature-list belongs to the pricing component and nowhere else.

That single rule is what replaced several overlapping systems with one. The practical result: anyone opening the project a year later finds a class by searching the component name, and knows from the name alone whether changing it touches one section or the entire site. The site stopped being something only its original author could edit safely.

2. A style guide wired to variable collections

Colour, spacing and typography moved into variable collections with semantic names, connected to a style guide, so background-primary and space-large are decided once and referenced everywhere rather than living as a hex value somebody pasted into forty elements.

Spacing runs on rem across the site, with pixels kept only where pixels are the correct unit. Section padding comes from a small set of steps rather than a value chosen per section.

The result is dull to describe and it is why a page added two years later sits on the same rhythm as the first one, without anybody measuring anything.

3. Heading structure separated from heading size

This is the change that moved the search numbers, and the least visible one on screen.

In a disordered project people pick a heading level for how large it looks. An H3 gets used because an H2 is too big, and the page ends up with a heading hierarchy that describes the layout rather than the content. Every page built that way is a page a search specialist has to argue about.

Client-First separates the two. The semantic level comes from the tag; the visual size comes from a utility class such as heading-style-h2. A section carries the correct H2 for its content and still looks however the design needs it to look.

Correct heading structure stopped being a negotiation between design and search and became a property of the templates. New pages inherited it without anyone remembering to apply it, and the search team's hours went back into publishing.

4. Components that crossed from Webflow into Next.js

Part of the site ran on Webflow and part on Next.js. Max Performance set up a Webflow DevLink pipeline so components built in Webflow could be used directly inside the Next.js application, which is how content and components moved between the two without a second copy of each component being maintained by hand.

Most teams are told a migration like that is not realistic. It is not realistic on a disordered site, which is a different statement from it being impossible.

5. A design system the company's own team builds on

In 2026 the site moved onto Astro. Max Performance designed the site and the design system; the company's own team completed the rest from inside, working with its search consultant and its marketing director.

That division is the engagement rather than a footnote to it. The deliverable was never a finished website. It was a structure complete enough that the people using it every day could keep building on it without an agency in the loop.

Astro earned the move on specifics, not on fashion: it ships static HTML with no framework runtime by default, so heading order, schema, internal links and the passages a model would quote are all under direct control and all present without JavaScript. That is the difference between optimizing for a crawler and optimizing for something that has to parse and cite the page.

The structure came across intact, which is the test a system either passes or fails. Most fail it.

Outcomes

Why it worked: nobody was doing it alone

Max Performance rebuilt the front end, built the page system and designed the design system. The search strategy belongs to the company's search consultant; the content and the day to day running of the site belong to its marketing team.

Saying which is which is the point of the case rather than modesty. The search work was already good before Max Performance arrived and on its own it was not producing this. Part of the company's online growth, and of the demo requests that came with it, sits exactly where the three overlap: the strategy, the team running it, and the structure underneath.

The uncomfortable version of the lesson: a marketing site rarely limits a company by being ugly. It limits them by how many decisions it takes to add a page correctly.

What this means for other contact center software companies

If you are paying for search work while nobody can fully explain how your site is built, you are paying for output you cannot ship. A redesign resets the appearance and leaves that untouched.

Three things worth taking from this:

1. Buy the structure, not the redesign. Ask any agency which published naming standard they build to, and what happens when you need page twenty-three. If the standard is their own invention, the answer is unverifiable and you are buying a dependency.
2. Insist that heading level and heading size are independent. If they are not, your heading structure will describe your layout instead of your content on every page, permanently, and your search budget will be spent on corrections.
3. Judge the handover, not the launch. The question is whether your own team can extend the site a year later. If the answer depends on the agency still being there, you bought a website rather than a system.