Branding

Component AreaBrand-aware UIShared identity

Branding in Fast Unicorn is not limited to changing a logo.

It is the layer that gives the product a consistent identity across:

  • metadata
  • navigation
  • email
  • dashboard shell
  • marketing site
  • error states

Where to start

If you want to change the visible product identity first, pair this page with First Customization and Customize Branding.

What this component area includes

Brand source of truth

Shared brand settings are centralized so names, metadata, and asset paths do not drift across the app.

UI integration points

Branding flows into navigation, dashboards, metadata, email settings, and fallback visuals.

Asset organization

Logos, error imagery, and marketing visuals are grouped into predictable public folders.

Main files and folders

  • src/config/site.ts
  • src/components/ui/logo-theme-handler.tsx
  • src/components/ui/theme-switcher.tsx
  • public/logos
  • public/errors
Brand model

Source of truth

src/config/site.ts is the main branding source of truth.

It currently controls:

  • site name
  • site description
  • support/contact email
  • transactional sender
  • main logo
  • text logos
  • sidebar logo
  • error imagery

This makes it easier to update product identity without hunting through route files and component trees.

Where branding appears

Branding flows through multiple parts of the app:

  • page metadata in the root layout
  • logos in shared navigation
  • dashboard sidebar identity
  • email sender details
  • error and empty-state visuals

The result is a brand layer that affects both public-facing and authenticated surfaces.

Asset strategy

Keep brand assets organized and predictable.

Recommended responsibilities:

  • public/logos for app and navigation branding
  • public/errors for fallback and error-specific imagery
  • public/hero and public/characteristics for marketing storytelling

Good branding boundary

If a change affects the public identity of the product, start in config and assets before editing component code.

Practical rule

If a change affects the public identity of the product, start in src/config/site.ts before editing component code.

That keeps branding centralized and avoids scattering hardcoded names, paths, or copy across the app.