Our new marketing site doesn't match our product UI — does that matter?

The redesign almost always stops at the login screen. The marketing site is a website. The product is software, with a different owner, a different release cycle and a different appetite for risk. So the new site ships with a new grid, new type and a new accent colour, and the product still looks like it did last year.

That gap is normal. People know they have crossed a boundary when they log in, and they expect the inside of a product to look different from the shop window. Nobody files a ticket because the corner radius went from 4px to 8px.

What they do not forgive is a break in the things they carry across the boundary. The name of the plan they just bought. The word for the button that finishes a job. The colour that told them an action was safe. Those things travel with the user, and when they change halfway through a session, the user stops and re-reads.

When clients come back six months after a marketing site launch worried about the mismatch, we ask what users have actually said. The complaints are never about colour or type.

In our projects the ones that arrive look like this. A pricing page renamed a tier from Pro to Business, and the billing screen still said Pro, so people wrote in to ask whether they were on the right plan. A nav item that existed on the old site vanished from the new one, and the product’s help links still pointed at it. And the sharpest one: an accent colour that meant confirm on the marketing site and delete inside the product, on buttons that sat in the same position on the page.

None of those cost much to fix. The rename was a copy change in one CMS field and one product string. But each one generated support tickets for weeks, because the user is not confused about design. They are confused about what will happen if they click.

Do this before anyone quotes you for a second project. It takes an afternoon and it usually shrinks the job to something your existing team can ship.

Mark each difference as one of three kinds. Cosmetic is shade, corner radius, font weight, spacing. Semantic is what a word, a colour or a control means. Structural is where things live and what the navigation offers.

1. List every surface one user crosses in a single session: the marketing page they landed on, signup, the empty state after signup, billing, support docs, and the transactional emails they get along the way.
2. Put the pair either side of the login boundary side by side for each step, and label every difference cosmetic, semantic or structural.
3. Fix semantic first. It is the cheapest kind and the only kind users report. Usually it is copy and a colour rule, not a rebuild.
4. Fix structural second, and only where the journey actually crosses. If nobody goes from the product back to the pricing page, a mismatched nav there is not a problem.
5. Leave cosmetic alone until the product is being rebuilt for another reason.
6. Write down the shared vocabulary and give it to whoever ships next on either side.

The document that fixes semantic drift is short. Plan names, exactly as they appear on the invoice. The verb for the primary action, so it is Save everywhere or Update everywhere, not both. What your accent colour is allowed to mean, and what colour destructive actions get. The name of each object in the product, singular and plural, so the site does not sell Workspaces while the app shows Teams.

One page, in whatever wiki both teams already read. Everyone who ships next on either side of the login wall gets it. That is worth more than a shared component library nobody can install.

A shared design system across a marketing site and a product is a real option, and we build one when both sides are in scope. But two codebases on two stacks sharing components is a maintenance cost you pay forever for a benefit nobody can measure. If a change to a button now needs two releases and two reviewers, the library is slowing you down.

Rebuilding a working product UI so it matches a new marketing site is a redesign for the studio’s portfolio, not for your users. If the product works and nobody is complaining, that money buys you nothing you can point at.

Cheaper things that are usually enough, in the order we would try them. Align the words and the meaning of your colours, which costs a day of someone’s attention. Share the header and footer only, so the frame around the two experiences matches. Copy the type scale and the core colour values across by hand, once, and accept they will drift again. Or do nothing, which is the right answer more often than a studio will tell you.

There is a real case for redesigning both together: when the product is being rebuilt anyway, or when the signup flow itself is the thing that is broken. That is what our app and marketing website engagement is for, and it runs two to three months rather than the two to three weeks a marketing site takes. If neither of those is true for you, wait.

Set a reminder for three months after launch and check two things.

Support tickets. Search them for the words on your new pricing page. If people are quoting a plan name, a feature name or a price back at you and asking which one is right, semantic drift has reached your users and the vocabulary page needs updating.

Signup drop-off. Compare the step where people leave now against the same step before the new site launched. A drop between clicking the marketing call to action and finishing signup usually means the promise changed at the boundary: a different price, a different plan name, a card form nobody was warned about. That is worth fixing. A steady funnel with a product that looks five years older than the site is not a problem. It is just two things built at two different times, which is what almost every software company looks like from the inside.