The white-label audit is the checklist we run before a release to
confirm that a buyer renaming the install to Acme Assist
sees Acme Assist on every customer-facing surface — never
a stray "Pitchbar" sneaking through. This page is the audit
template; it lives in docs so any future engineer can re-run it
and update the same surface inventory in place.
Test method
-
Set
site_title = "Acme Assist" in
/settings/branding, swap header logo + favicon
to dummy art, set the footer brand label to "Acme", and (on
a paid plan) flip Remove "Powered by" on.
-
Walk the surfaces below, signed out for the marketing /
widget rows and signed in (as a customer + as a super-admin)
for the dashboard / settings rows.
-
Grep the codebase for hard-coded literals on the way in:
grep -rn "Pitchbar\|pitchbar\.ai\|@pitchbar\.com" \
--include="*.tsx" --include="*.ts" --include="*.blade.php" --include="*.php" \
--exclude-dir=tests --exclude-dir=vendor --exclude-dir=node_modules \
resources app routes
Filter the result by surface (anything in resources/views/documentation/
is allowed to name the source product; user-facing surfaces are not).
Surface inventory (last run: 2026-05-09, v1.1.0)
Auth (Fortify)
| Surface | Status | Notes |
|---|
| Login / register / forgot-password card |
✅ pass |
auth-simple-layout.tsx reads
branding.site_title; falls back to
'Pitchbar' only when the install has no
brand set. Title bar, brand mark, and copy honour the
rebrand.
|
| Email-verification + password-reset emails |
✅ pass |
Mail templates use config('branding.site_title')
via AppBranding::siteTitle() — Fortify's
stock Laravel mailable is overridden in
AppServiceProvider to use the
white-labelled view.
|
Dashboard shell
| Surface | Status | Notes |
|---|
| Sidebar brand mark + tooltip |
✅ pass |
useBranding().site_title drives both. |
| Sidebar "Set up X in a few steps" |
✅ fixed in v1.1.0
|
Was hard-coded as "Set up Pitchbar". Now reads
branding.site_title.
|
| Breadcrumbs / page titles |
✅ pass |
Driven by config('app.name') +
branding.site_title shared via Inertia.
|
| Workspace dropdown / impersonation banner |
✅ pass |
No brand strings — just user / workspace identifiers. |
Marketing site
| Surface | Status | Notes |
|---|
Home (/) — hero / chat preview / footer |
✅ pass |
Drives every brand-facing string from
landingContent +
useBranding(). The shipped defaults DO
say "Pitchbar" — but those are JSON content the admin
edits via Settings → Marketing.
|
| Pricing / How it works / Integrations / Privacy / Terms |
✅ pass |
All Inertia-rendered. marketing-shell.tsx
applies the rebrand. The Blade
resources/views/marketing/_layout.blade.php
file is dead code (no longer routed).
|
Public /changelog |
✅ pass |
ChangelogController::show shares the
branded site_title; the entry body is admin-authored so
"Pitchbar" only appears if the admin types it.
|
| Marketing footer "© Pitchbar..." |
✅ pass |
Driven by landingContent.footer.copyright;
editable from Settings → Marketing.
|
Widget (visitor surface)
| Surface | Status | Notes |
|---|
| "Powered by ..." footer link |
✅ pass |
Server-resolved branding.label from
AppBranding::shared(). Hidden entirely on
paid plans that strip Pitchbar attribution.
|
| Demo pill ("Live demo ·") |
✅ fixed in v1.1.0 |
Was "Live demo · ask anything about Pitchbar". Now
"Live demo · ask the sandbox agent anything" — generic
so any white-label install can keep the same widget
bundle.
|
| Launcher label / chat header / agent name |
✅ pass |
Per-agent theme.launcher_label +
persona.name. Buyer-controlled.
|
window.Pitchbar.mount() global |
⚪ accepted |
Protocol concern — embed snippets in the wild already
key on this name. Renaming would break every existing
buyer's installation.
|
Outbound emails
| Surface | Status | Notes |
|---|
Captured-lead notification (NewLeadCaptured) |
✅ pass |
Subject + body use AppBranding::siteTitle()
+ the white-labelled lead-capture template.
Test with the new "Send test lead email" button on
Settings → System → Mail.
|
| Stripe receipt (cashier) |
✅ pass |
White-label cascade applies —
cashier.invoices.from_address +
from_name resolved from
AppSetting.
|
| PayPal / Razorpay receipts |
✅ pass |
Notification templates pull from
AppBranding::siteTitle(). Round-tripped on a
renamed install.
|
| Paddle / Iyzico / PayU receipts |
⏸ deferred |
Gateway integrations not yet shipped (cards #12, #13,
#14). Re-run this audit row once the gateway code lands
so the email templates inherit the same white-label
cascade.
|
Documentation pages
| Surface | Status | Notes |
|---|
/documentation/* Blade pages |
⚪ accepted |
Documentation describes the source codebase by name.
Buyers running a white-label install can edit the
Blade files directly to substitute their own brand —
we don't auto-rebrand docs because the project name
("Pitchbar") is part of the source identity that the
buyer is licensing.
|
Summary
- 2 leaks fixed in v1.1.0 — sidebar onboarding text + widget DEMO pill.
- 0 leaks open on customer-facing surfaces today.
- 3 deferred rows — Paddle / Iyzico / PayU email templates, blocked on the gateways themselves landing.
-
1 accepted by-design —
window.Pitchbar.mount()
global, kept as a protocol identifier. Documented under
Embed the widget.
Re-run this audit on every release that touches an outbound email,
a marketing surface, the widget bundle, or a Fortify auth flow.
The grep one-liner at the top makes it a 5-minute job.