brand system

application / marketing

activemenu

application / marketing system

marketing

Reusable surface recipes for the homepage, /for pages, and compare pages.

marketing

active

one page, many routes.

landing, audience, and comparison pages share the same building blocks.

/
/for
/compare

01 / application spine

homepage first, reusable by design

The brand should grow out of the live landing page, not around it. This tab turns current landing patterns and growth docs into reusable building blocks for homepage, audience, comparison, story, and future SEO pages.

pawr.link
shared blocks

one pawrful page.

The homepage stays the flagship. SEO pages inherit its parts, then swap audience, proof, palette, and route-specific facts.

block

hero

block

proof

block

CTA

/

homepage

full flagship rhythm

/for/cafes

audience page

same parts, specific proof

/compare/linktree

comparison page

facts, tradeoffs, freshness

02 / current landing surfaces

reuse what already works

This is the audit layer: each homepage surface gets a future reusable shape, what should stay intact, and the failure mode to avoid when SEO pages start borrowing it.

01

LandingHero / ClaimForm

hero + claim

explain the page and start the signup flow

reusable as

MarketingHero + ClaimCtaBand

page-first pitch, proof line, product video, Privy-first CTA behavior

avoid

SEO pages cloning the homepage hero instead of using audience-specific proof

02

LandingFeatureDemos

feature demos

show the product doing useful work

reusable as

FeatureDemoRow

small number of concrete demos with real UI or exportable media

avoid

feature copy becoming generic SaaS bullets without a visible page outcome

03

LandingPricing / plan features

pricing

explain trial, pawr, and lifetime without derailing discovery

reusable as

PricingPanel

yearly default, plan-feature constants, keep-the-pawr lifecycle language

avoid

audience pages inventing separate pricing cards or CTA behavior

04

LandingUseCases

use cases + manifesto

make the product feel useful for many kinds of people

reusable as

UseCaseRail + ContrastBlock

proof through screenshots, not abstract icons

avoid

turning every page family into a different visual theme park

05

LandingFeedback / showcase cases

feedback + proof

prove that real pages exist and carry personality

reusable as

ProofRail

cached profile previews, latest feedback resolver, real page examples

avoid

hardcoded image URLs or stale testimonial blobs

06

LandingAgents

agents + technical audience

make AI/agent readability legible without leading the whole brand

reusable as

TechnicalUseCasePanel

plain page value first, technical pitch second

avoid

making protocol language the default homepage voice

03 / reusable blocks

the production component inventory

These are the blocks worth treating as shared production parts. The block list is intentionally broader than the homepage so `/for` and `/compare` can share the same styling contract.

hero

marketing hero

sets page family, audience, and first CTA

//for/*/compare/*/story

style contract

one sharp headline, one support line, one proof object, no nested cards

components/marketing/marketing-hero.tsx

claim-cta

claim CTA band

keeps signup behavior consistent

//for/*/compare/*/keep

style contract

ink-first CTA unless a campaign module earns one accent button

components/marketing/claim-cta-band.tsx

feature-demo

feature demo row

turns a product behavior into visible proof

//for/*/compare/*

style contract

real UI, screenshot, or route-backed preview before illustration

components/marketing/feature-demo-row.tsx

pricing-panel

pricing panel

keeps trial, pawr, and lifetime consistent

//for/*/keep

style contract

shared plan constants, yearly-first, no one-off tier names

components/marketing/pricing-panel.tsx

use-case-rail

use-case rail

shows many page outcomes without rebuilding the brand per audience

//for/*

style contract

screenshots and profile examples supply most color

components/marketing/use-case-rail.tsx

proof-rail

proof rail

uses real pages, quotes, and cached OG previews as evidence

//for/*/compare/*

style contract

blob-backed images or route-backed previews, never rot-prone hardcoded URLs

components/marketing/proof-rail.tsx

contrast-block

contrast block

explains what pawr refuses or replaces

//compare/*/story

style contract

opinionated, short, balanced by concrete product behavior

components/marketing/contrast-block.tsx

recipe-grid

page recipe grid

shows what an audience page should contain

/for/*

style contract

typed modules from audience config, one field palette per route

components/marketing/audience/page-recipe-grid.tsx

comparison-table

comparison table

lets comparison pages answer evaluation intent quickly

/compare/*

style contract

balanced facts, source links, freshness date, crawlable content

components/marketing/compare/compare-table.tsx

faq

FAQ stack

captures long-tail questions without bloating the pitch

/for/*/compare/*/story

style contract

server-rendered question/answer pairs from typed configs

components/marketing/faq-stack.tsx

related-links

related route links

keeps SEO pages browseable and honest

/for/*/compare/*

style contract

browseable IA, no orphan doorway pages

components/marketing/related-route-links.tsx

04 / SEO route recipes

two route families, two jobs

Audience pages and comparison pages should share components, but they should not sound or behave the same. Audience pages prove fit; comparison pages help someone make a decision.

/for/*

audience pages for distinct use cases

data model

typed audience config: hero, problem, page recipe, examples, setup, FAQ, related audiences

visual rule

One field color and one supporting accent per audience. Same architecture, different proof and microcopy.

required blocks

heroproblempage recipeexample griduse casessetup stepsrelated audiencesFAQCTA

guardrails

distinct audience and intent

distinct proof, not doorway copy

real page examples where possible

crawlable server content

production files

app/for/page.tsxapp/for/[audience]/page.tsxlib/seo/audience-pages.tscomponents/marketing/audience/*

/compare/*

evaluation pages for alternatives and tradeoffs

data model

typed competitor config: verdict, lenses, comparison rows, strengths, tradeoffs, sources, FAQ

visual rule

Calmer than audience pages. Use tables, verdict panels, source rows, and proof blocks more than campaign color.

required blocks

hero verdictquick comparison tabledecision lensespawr strengthscompetitor strengthstradeoffsmigration notesFAQ

guardrails

official sources for current claims

visible freshness date

balanced verdict

no fake metrics or fake authority

production files

app/compare/page.tsxapp/compare/[competitor]/page.tsxlib/seo/compare-pages.tscomponents/marketing/compare/*

05 / route palettes

directional starters, not strict themes

Route families can get useful color guidance without forcing the brand into a single hue. The baseline rule stays: one field palette, one accent, real proof carries the rest.

/for/cafes

member warmth

gold flash / coral red

warm, owned, physical-place energy without turning the whole site beige

/for/coffee-professionals

creator showcase

creator green / signal blue

skill and profile vitality with enough contrast for examples and service proof

/for/creators

creator showcase

creator green / gold flash

profile content should be the loud object; the field stays soft

/for/agents

agent lab

violet pulse / signal blue

marks experimental/technical context without making AI the default brand

/compare/*

docs quiet

ink / signal blue

comparison intent needs clarity, tables, and evidence more than campaign mood

06 / implementation rules

how this becomes maintainable

These rules keep the brand system maintainable as it becomes shared components. They protect against one-off SEO pages, color drift, duplicate CTAs, and fact strings scattered across TSX.

01

recipes before raw JSX

Future growth pages should compose named marketing blocks and recipe props first.

If a page needs custom styling, promote the stable pattern into a shared block instead of cloning utility strings.

02

screenshots carry color

Marketing surfaces should let product screenshots, profile previews, and real pages supply most of the color.

Use one field palette per route family and avoid vivid backgrounds behind already colorful proof.

03

Baloo stays scarce

Baloo 2 belongs to the wordmark and biggest growth-display beats, not dense page chrome.

SEO pages should use neutral sans for body, tables, FAQs, pricing detail, and comparison rows.

04

SEO content is crawlable

Audience and comparison pages need server-rendered text, metadata, internal links, and real headings.

Do not hide the actual page argument inside images, videos, or client-only interactive blocks.

05

facts live in configs

Compare claims, freshness dates, route relationships, and audience recipes should be typed data.

Update a data file and let components render it. Avoid fact strings embedded across TSX sections.

06

one architecture, many applications

Audience pages can feel specific without becoming separate microsites.

Change palette, proof, example composition, and microcopy. Keep mark, typography, spacing, CTAs, and section rhythm stable.