Skip to main content

Branding in the Environment, Not the Code

Company name, logos, support contacts, color palette, email footer copy, physical address — all the things that identify a deployment as DTC's — live in environment variables. Not hard-coded strings in the source.

The rule: the same compiled binary ships to any tenant. What changes is the environment it runs in.

What this looks like

# .env.prod
PORTAL_COMPANY_FULL_NAME="DTC, Inc."
PORTAL_COMPANY_SHORT_NAME="DTC"
PORTAL_COMPANY_ADDRESS="920 Ridgebrook Rd, Suite 120 · Sparks Glencoe, MD 21152"
PORTAL_COMPANY_WEBSITE=https://www.dtctoday.com
PORTAL_SUPPORT_EMAIL=helpdesk@dtctoday.com
PORTAL_SUPPORT_PHONE=410.877.3625
PORTAL_BANNER_LOGO_URL=https://cdn.jsdelivr.net/gh/DTC-Inc/static@release/brand/banner-logo.jpg
PORTAL_QUOTE_COVER_IMAGE_URL=https://cdn.jsdelivr.net/gh/DTC-Inc/static@release/brand/dtc-quote-cover-image.png

Code reads these at boot and surfaces them wherever branded content appears (email footers, page headers, support sections, etc.). Strings with "DTC" literally in them don't appear in Rust/TypeScript source files unless they refer to internal-to-DTC concepts that aren't consumer-facing.

What this enables

  • White-labeling. If DTC ever resells this portal to another MSP, branding is an env change, not a fork.
  • Environment-specific branding. "Dev Portal" banner in dev, real branding in prod.
  • Brand updates without a rebuild. New logo URL? Update env var, restart, done. No code change, no release cycle.
  • Testing with synthetic branding. Staging environments with obviously-fake "TEST CO" branding so no one mistakes a test run for production.

The binary-naming corollary

This extends to binary names and package identifiers. In the Client Portal v2.0.0:

  • Rust binary: client-portal-api (not dtc-client-portal-api)
  • Worker binary: client-portal-worker
  • Rust crate: client_portal_api
  • npm package: client-portal-web
  • Docker images: ghcr.io/dtc-inc/client-portal-api, ghcr.io/dtc-inc/client-portal-web

The only DTC-specific name appears in the Docker registry namespace (dtc-inc). Everything internal is vendor-neutral. If we moved the registry to a different org, the binaries wouldn't change name.

What's NOT in env vars

  • Code logic that only makes sense for DTC (e.g., HaloPSA integration specifics — Halo is a product name, not a brand identity).
  • Absolute product conventions that any future reseller would inherit (our version number, our database schema names).
  • Technical identifiers that happen to be DTC-prefixed by historical convention (OUIDs, audit field names) — those can stay, but any new ones should avoid the pattern.

The test: "Could another MSP buy this codebase tomorrow and deploy it with their branding?" If yes, we're doing it right. If no, find the hard-coded string.

Why we do this

  • Legal. Company name changes (M&A, rebrand) don't require a code release.
  • Commercial optionality. If selling the platform becomes interesting, the hard part is already done.
  • Testing clarity. Branded-as-test staging environments prevent prod mistakes.
  • Reader clarity. "DTC, Inc." appearing in source code looks like application logic; as an env-injected string, it's obviously configuration.

When this applies

Any user-facing string, image URL, color, or contact identifier that represents the company operating the system.

When it does not apply

  • Internal-only tools that only DTC staff interact with, where there's no commercial value in decoupling from our identity.
  • Migration scripts, seed data, or test fixtures that reference specific real-world entities (DTC's own client ID in a dev seed, for example).
Back to top