Customize Branding

GuideBrand setupConfig-first changes

Most branding changes can be made through config files, content JSON files, and static assets.

That means you can make the product feel like your own without rewriting route components or touching lower-level architecture too early.

What this guide covers

Identity

Product name, metadata, contact details, sender settings, logos, and error assets.

Content

Landing copy, navigation labels, documentation cards, pricing, FAQ, and footer links.

Assets and locales

Static image replacements and translation updates that keep the experience consistent.

Main files and folders

Folder path	Description
`src/config/site.ts`	Update the product name, description, and brand metadata.
`src/config/marketing.ts`	Update the marketing copy for the hero section, pricing, FAQ, and footer.
`public/logos`	Update the logo assets.
`public/hero`	Update the hero assets.
`public/characteristics`	Update the characteristics assets.
`public/testimonials`	Update the testimonials assets.
`public/errors`	Update the error assets.
`public/auth`	Update the auth assets.
`messages/en.json`	Update the localized copy for the English locale.
`messages/es.json`	Update the localized copy for the Spanish locale.
`messages/cn.json`	Update the localized copy for the Chinese locale.

Branding workflow

1. Update site identity

Edit src/config/site.ts to change:

product name
description
contact email
Resend sender address
logo asset paths
error page asset paths

This file is the single source of truth for brand-level metadata.

Why start here?

Once the brand identity is defined, it becomes much easier to keep the rest of the landing content, email settings, and assets aligned with the same product direction.

2. Update landing content

Edit the locale-specific JSON files in content/landing/ (e.g. en.json, es.json, cn.json) to customize:

hero content
social proof copy
documentation cards
testimonials
FAQ
pricing
final CTA
footer content

Each JSON file is validated by Zod schemas defined in src/content/schemas.ts and loaded by src/content/loaders.ts. This is where the product starts to stop feeling like a starter template and starts sounding like your company.

3. Replace assets in `public/`

The current template expects brand assets under:

public/logos
public/hero
public/characteristics
public/testimonials
public/errors
public/auth

Swap these placeholders as early as possible if you want the interface to feel consistent across marketing, auth, and fallback pages.

4. Update translations

Localized UI labels live in per-locale directories under messages/. Each directory contains separate JSON files:

messages/en/ — system.json, navbar.json, dashboard.json, auth.json
messages/es/ — same structure
messages/cn/ — same structure

When you change labels referenced by components, make sure the matching translation keys exist in all supported locales.

Translation consistency

If one locale is missing a key that your config expects, parts of the UI can become incomplete or inconsistent across languages.

5. Review email sender details

The transactional sender address comes from siteConfig.resendEmail in src/config/site.ts.

Before sending production emails:

verify your domain in Resend
use a sender from that verified domain
test auth and billing email flows locally and in staging

Final check

Checklist before moving on

Define the product identity

Update the main site config so metadata, contact details, and default assets reflect your real brand.

Replace visible content

Rewrite the landing content in content/landing/*.json until the site speaks in your product voice.

Swap placeholder assets

Replace logos, visuals, and error illustrations so the product no longer looks like a starter.

Align every locale

Make sure translated copy stays in sync with the labels and messages referenced by config.

Validate email sender settings

Confirm your Resend domain and sender identity before testing transactional flows in real environments.

Branding is usually the safest first customization layer because it gives you immediate product clarity without forcing architectural changes too early.