Branding and internationalization

The delivered application intentionally uses a neutral Example SaaS identity and example legal and marketing content. Replace that presentation layer before production while keeping the underlying auth, billing, credits, and provider boundaries intact.

Replace the permanent brand identity

Start with src/lib/config/brand.ts. It owns the non-translated brand details used across the app:

• canonical domain and URL
• support, legal, and privacy email addresses
• legal company name and jurisdiction
• social links
• infrastructure-facing project slug and auth cache key

The rendered brand.name normally comes from seo.common.siteName in the English marketing messages. Update that value in every active locale:

src/i18n/locales/en/marketing.json
src/i18n/locales/zh/marketing.json
src/i18n/locales/es/marketing.json

Also replace titles, descriptions, authors, Open Graph copy, and Twitter copy under the marketing SEO section. Search all three locale files for Example SaaS after editing.

Deployment-specific name override

Two optional public variables can change the rendered wordmark without editing source:

NEXT_PUBLIC_BRAND_NAME=Your Product
NEXT_PUBLIC_BRAND_WORDMARK_ACCENT=Product

This is useful for a temporary preview. It does not update the canonical domain, contact addresses, legal entity, localized body copy, or product content. A real rebrand still requires source changes.

Replace assets and theme tokens

The marketing header renders the BrandName text component rather than public/logo.svg. Metadata explicitly references /icon.svg, and the delivered source also contains src/app/favicon.ico; replace and verify both icon surfaces to avoid browser and crawler mismatches.

Change the CSS variables in both :root and .dark. Tailwind utilities such as bg-primary and text-accent map back to those variables, so most components update without editing their class names.

The Open Graph image is generated from the centralized brand configuration. Review it after changing the name, tagline, colors, and domain.

Rewrite product content

The main buyer-owned content surfaces are:

The included legal text is an example and explicitly not legal advice. Replace it with policies reviewed for your business, providers, jurisdiction, refund policy, and data handling.

How localization is organized

VibeAny uses next-intl with locale-prefixed routes. The active locales are en, zh, and es, with en as the default and translation source.

Routing is configured in src/lib/i18n/routing.ts. Locale messages live in src/i18n/locales/<locale> and currently expose eight top-level namespaces:

• common
• auth
• dashboard
• marketing
• media
• payments
• legal
• storage

Each locale's index.ts imports those JSON files into the object supplied to NextIntlClientProvider.

Edit translations safely

1. Add or rename the key in the English JSON file first.
2. Add the identical key structure to Chinese and Spanish.
3. Translate values, not keys.
4. Preserve interpolation placeholders and structured arrays or objects expected by UI schemas.
5. Run validation and coverage before committing.

npm run i18n:validate
npm run i18n:coverage

i18n:validate compares every locale's files and key paths against English. i18n:coverage reports empty values; it does not assess translation quality.

Client components read messages with useTranslations('<namespace>'). Server components use next-intl server helpers. Use the locale-aware navigation exports in src/lib/navigation.ts instead of constructing locale prefixes by hand.

Add or remove a locale

Locale support is coordinated across routing, loading, validation, and SEO. Do not only copy a folder and edit one list.

For a new locale, update at least:

1. src/lib/i18n/routing.ts
2. src/i18n/locales/<new-locale> and its index.ts
3. the explicit loader cases in src/i18n/utils.ts
4. locale lists in the i18n validation, coverage, and namespace scripts
5. locale handling and language alternates in src/lib/seo.ts
6. src/app/sitemap.ts
7. marketing.json alternate-locale metadata in every locale
8. authentication email locale types and templates if the new locale needs localized auth mail

Run npm run i18n:validate, npm run typecheck:all, and npm run build after the change, then exercise the new locale's home, auth, legal, pricing, dashboard, and metadata routes.

Authentication email language

Authentication email templates currently live in src/lib/auth.ts. Although English, Chinese, and Spanish message sets exist there, the verification and reset callbacks currently request English explicitly. Customize that selection if your product must send mail in the user's preferred locale.

Rebrand acceptance

Before launch:

• search active UI, metadata, email, blog, and legal content for the example identity
• verify the logo and icon at light and dark contrast levels
• inspect localized metadata and the generated Open Graph image
• check that every locale has equivalent keys and intentional copy
• run npm run i18n:validate, relevant tests, and npm run build

Treat npm run rebrand:validate as an additional residual-reference check, not proof that all Example SaaS content has been replaced. The current script's historical template baseline does not cover every buyer-owned placeholder.

Continue with Environment configuration or Authentication and email.