Keep your marketing site consistent with product UI (shared system, not identical screens)

Buyers ask which platform keeps a marketing site visually consistent with the product. The platform is downstream. The scarce decision is whether marketing and product share one system, or whether each surface invents its own.

Recognition is the goal. A visitor lands on the marketing site, signs up, and opens the product. If those two experiences feel like different companies, cloning app screens onto the marketing site will not fix it. Shared tokens and brand invariants will. Density, type scale, and motion stay free to diverge, because the jobs are different.

As of the 17 Sep 2026 export, Google Search Console showed 0 clicks, 4 impressions, 0% CTR, and position 8 for "which platform is best if i want to keep a marketing site visually consistent with the product?". Small numbers. Cited because they are real, not because they look like a market. People who notice the drift reach for a platform answer. The answer sits earlier in the stack.

Consistent vs identical

Marketing persuades. It needs room, a claim, and enough quiet that a first-time visitor can decide. Product helps someone finish a task. It needs density, repeatable controls, and a hierarchy built for daily use.

Teams lose the plot when they treat "consistent" as a synonym for "identical." Pixel parity is the failure mode. The marketing page starts to feel like a stretched settings screen. The product starts to feel like a landing page that cannot be operated. Neither job gets done.

Stripe and Shopify are the examples people already have in mind. You recognize the company from the marketing site, and the product still feels like that company, without the dashboard being a copy of the homepage. We are not going to invent their token architecture or claim a measurement we did not take. The pattern is recognition without replication. That is the distinction worth holding.

The educational frame already exists. Inkbot's 2026 piece, Unified SaaS Design System: Consistent, Not Identical, walks the argument in public. Adobe Design's write-up of Consonant on Spectrum is the enterprise case: a marketing system that extends the product system for Adobe.com instead of cloning product templates onto the marketing site. This page will not re-tutorial either one. Neither one turns that decision into a partner who ships both surfaces. That is the open lane, usually after a rebrand, or when a team is choosing a marketing builder and fears a second design system.

What must stay invariant (and what should diverge)

Some decisions carry meaning. Change them on one surface and you have changed the brand, not the layout. Other decisions are how a surface does its job. Forcing them to match is how you get a marketing site that feels like an admin panel, or a product that feels like a brochure.

Invariant. Logo and mark meaning. Core color meaning (what the color signals, not how much of the page it covers). Type voice. Tone. Icon style. Accessibility, including contrast, focus, and the rule that text still works when someone is not looking at a hero. These live in one token source of truth. Both surfaces consume them.

Divergent on purpose. Color application ratio. Type scale. Density. Motion. A marketing hero can spend the brand primary across a large field because it is making a first impression. The product can use that same primary as a thin action color because it is guiding a task. Same meaning. Different ratio. That is not drift.

The version you can quote: consistent, not identical: shared tokens, surface-local density.

A mechanical test keeps the argument honest. Change the brand accent in one place, the token source, and see whether both surfaces move. If they do, they share meaning. If only one moves, the other surface is running on local styles and the "design system" is a logo on top of two palettes. Skills Directory's marketing vs product system note states the same rule: brand values are shared, application values are chosen per surface, and the token layer underneath must stay single.

There is a real counterexample, and it is worth naming so you do not confuse it with neglect. Daniel Pertu's DEV write-up describes tokens as a package, with the marketing site deliberately not a consumer. Colors are hand-maintained as CSS custom properties. Radii differ on purpose (rounder corners on the landing page than on the phone UI). The residual risk is stated, not hidden: a few strings typed by hand will drift, and someone has to look. That is intentional divergence for a specific product. It is not Clearly's default.

Our default is one source, and every platform as a consumer, with surface-local scale applied where the surface is built. Hand-copying the accent into Framer "for now" is how the example above happens. If you choose the non-consumer path, write down what is allowed to differ and who checks the residual risk. Do not call an unowned copy a system.

Platforms as consumers, not competing systems

Framer, Webflow, and React are not three design systems. They are three ways to ship a surface. Drift shows up when each one is built as if the others do not exist. Independence feels practical. It produces a second brand faster than most teams expect.

The way out is one token source those tools consume. Tokens say what the brand means. Each platform implements that meaning in its own primitives: Framer color styles, Webflow variables, React and Tailwind theme values. The implementation differs because the tools differ. The meaning does not.

If you are choosing a builder because you are worried about consistency, features are the wrong first question. The first question is whether the builder can consume a token source, or whether every color becomes a local style nobody else can see. Who edits the site in six months, how much CMS you need, and whether Framer or Webflow fits that editing model: that comparison already exists. It is Webflow vs Framer for a SaaS marketing site. This page will not retell it. Builder choice sits downstream of the shared system. It does not replace it.

Custom React is the same shape. A marketing site and a product can share Next.js and still be two systems if marketing hardcodes hex values and product owns the real tokens. Sharing a framework is not sharing a system.

For teams on Tailwind, runtime wiring lives in design tokens and Tailwind v4. We will not rewrite that article. The marketing site and the product should resolve the same names. If marketing says brand-primary and product says blue-600 for the same meaning, you already have two vocabularies.

Coding agents make the gap louder. A session that can see the product repo and not the marketing tokens will invent a plausible palette. A session pointed at a Framer file with local styles will not know the React token changed last week. The contract for that is DESIGN.md and Taste Profile: what exists, what it means, and what an agent is not allowed to invent. The process for stopping one-off brand passes is AI UI brand governance. Those pages own the file and the governance. This page owns the marketing-and-product decision those tools have to serve.

Where Clearly fits

DIY is the right call when one team can keep a single token source, write the invariants down, and point every surface at that source. Do the mechanical test. If both surfaces move, you are done with the architecture. Keep the divergence list current so the next redesign does not "fix" it.

Partner when the gap is ownership across both surfaces. Growth runs the marketing site. Product runs the app. Nobody is chartered to hold the shared layer, so each rebrand and each new component forks a little more. Or AI tooling is in the loop and every session amplifies the fork, because there is no contract that says what marketing and product must share. A file you meant to write is not the same as a system someone owns.

We are a prototype-first embedded design partner. We sit in the work, not a request queue. For this problem that means one system, then both surfaces: marketing in Framer or Webflow, product in React, tokens and a DESIGN.md Taste Profile when coding agents ship UI. We prototype the shared decisions (what the accent means, where density is allowed to change) before anyone rebuilds a homepage to look like the app, or restyles the app to look like the homepage.

Pricing below is from the live homepage. Confirm on clearly.design and homepage pricing before you buy. Pause or cancel anytime. No invented throughput claims.

Standard, $4,995/mo. One workstream at a time. Async, with weekly progress. Prototype-first discovery. Framer and Webflow. Slack and Looms. Pause or cancel.

Advanced, $7,495/mo. Two workstreams. Check-ins as needed. Engineering integration. Custom components in Tailwind (React or HTML). Prototype-to-production translation, plus the Standard stack. Two workstreams is the practical shape when marketing and product both need to move and you do not want them sequenced forever.

If the library is already a mess (three palettes, components nobody trusts, Figma and production disagree), start with a design system audit, not with a new marketing build on top of the fork. If the question is the engagement itself (how a partner works, what we will turn down), that is design partner for SaaS. This page stops at the consistency decision.

Related decisions

Each of these is a different job. Use them when you already know which question you are in.

• Contract. DESIGN.md and Taste Profile is the machine-readable file and the in-repo package agents cannot invent around.
• Agent drift. AI UI brand governance is the process: stop fixing outputs one by one, install a root system.
• Runtime tokens. Design tokens and Tailwind v4 is how the source reaches components. It is not the marketing-versus-product decision.
• Builder. Webflow vs Framer for a SaaS marketing site is which tool edits the marketing site. It is not which platform keeps marketing consistent with product.
• Partner. Design partner for SaaS is the embedded retainer when you want someone in both workstreams.
• Messy library. Design system audit is the readout when the system has already forked.

Your marketing site and your product do not need to look identical. They need to feel like the same company. Shared tokens. Surface-local density. If that source has no owner, the next rebrand will fork it again.