zsty.us

Before / After · Case Study

JP Taylor Group — seven brands run from one place instead of seven

  • Local Pro Services

This family of companies runs seven distinct brands — from metal roofing and RVs to dumpster rentals and wood stoves — and each one needed its own site, email, and someone watching the inbox. All seven now run from a single platform: every brand keeps its own web address and its own look, every lead pings the right team the moment it lands, and an improvement built once shows up on all seven at the same time.

The eighth site costs a config entry, not a rebuild — that's the whole argument for multi-tenant.
🔒jp-taylor-group.vercel.app
jackiej.events — modern site

At a glance

What this rebuild covers.

  • Design

    The web address a visitor types decides everything — which brand's look, menu, catalog, and copy they see — so seven completely different businesses ride one build without blurring together.

  • Theme & color

    Each brand keeps a fully distinct face: the metal-roofing company and the RV dealer share zero audience and zero styling, even though every line of machinery underneath is shared.

  • Security

    Each brand's customer data lives in its own sealed-off compartment — a dumpster-rental lead can never leak into the stove brand's records, and each brand can keep its own data-retention rules.

  • Customer notifications

    New leads, operational events, and review alerts fan out instantly to each brand's own team-chat channel, so the right person sees the right brand's signal with no shared-inbox triage.

  • Email

    Transactional email was built once as a shared service and inherited by all seven brands, and browser push notifications are self-hosted — no outside vendor sits between a brand and its subscriber list.

  • Agents

    A shared AI layer is wired into the platform once, so any of the seven brands can add assistant features without a separate integration project.

  • Speed

    On the day we captured screenshots the old main site wasn't answering at all, while the new platform responded instantly on every brand address.

Receipts — measured

Numbers that moved.

0
Brands served from one repo
was 0
0
Neon branches isolating brand data
was 0
7
Codebases to maintain
was 7
1
Third-party push vendors
was 1
  • 7 brands → 1 platform
  • 7 sites to maintain → 1
  • Every lead routed to the right team
  • 0 push-notification middlemen

The story

Problem · Insight · Build · Outcome.

  1. 01 · Problem

    Seven brands, and the web presence multiplied cost instead of reach.

    Every brand needed a site, email, lead capture, and someone to notice when a form came in. As separate builds, that's seven of everything — and the apex WordPress site was fragile enough that it was returning 503s by capture day.

  2. 02 · Insight

    The brands differ in paint, not plumbing.

    A dumpster-rental lead and a wood-stove lead need the same machinery: a fast page, a form, a database row, a Slack ping, maybe a push. Multi-tenant architecture builds that machinery once and lets each brand keep a fully distinct face.

  3. 03 · Build

    One repo, proxy routing, branch-per-brand data, shared rails.

    Next.js 16 with proxy.ts hostname routing; Neon branch per brand with shared Drizzle schema; SES email, self-hosted VAPID push, R2 media, Upstash, a Slack ops/leads/reviews router, and Vercel AI Gateway for the LLM surface — every brand inherits all of it.

  4. 04 · Pending

    The apex 503 is the loudest argument for cutover.

    At capture time jptaylorgroup.com returned 503 on every variant while the new platform answered instantly on the Vercel host. DNS cutover of the seven brand domains is the remaining step — flagged to the operator.

For the technically curiousHow it was done
  1. 01

    Where it started

    Seven brands — the JP Taylor Group umbrella, JPTI, Taylor Metal, Roseville RV, Load & Go Dumpsters, eMotorack, and Sierra Stoves — each with its own domain and audience, built as separate WordPress-era sites drifting independently. Seven of everything: hosting, patches, forms, email, and someone to notice when a lead came in. The apex WordPress site was fragile enough that it was returning 503 errors on every variant by the day we captured screenshots.

  2. 02

    The insight

    The brands differ in paint, not plumbing. A dumpster-rental lead and a wood-stove lead need the same machinery — a fast page, a form, a database row, a team ping, maybe a push notification. Multi-tenant architecture builds that machinery once and lets each brand keep a fully distinct face.

  3. 03

    The rebuild

    One codebase on our hosting platform, with hostname routing at the front door: the inbound domain maps to its brand's theme, navigation, catalog, and copy. A managed database holds a separate branch for each brand under one shared schema, and the shared rails — a transactional email service, self-hosted browser push, media storage and caching, a chat-channel router, and an AI gateway for language-model calls — were built once and are inherited by every brand.

  4. 04

    Data isolation as a feature

    Branch-per-brand isn't just tidy — it's a guarantee. Each brand's data plane is isolated, so leads for one company can never surface in another company's queries, retention and deletion policies can differ per brand, and a schema migration can be rehearsed on a single brand's branch before it touches the other six.

  5. 05

    What runs now

    Inbound leads, ops events, and review alerts fan out through the channel router to per-brand team-chat channels the moment they land. Web push goes straight from the platform to subscribers with no third-party push vendor holding the list — the audience stays first-party data. Standing up brand number eight costs a routing entry, a database branch, and a theme — not a rebuild.

  6. 06

    The remaining step

    At capture time the old apex answered 503 while the new platform responded instantly on its hosted address — the loudest possible argument for cutover. Pointing the seven brand domains at the new platform is the remaining step, flagged to the operator.

Architecture

Old stack
  • Per-brand WordPress
  • Seven sites, seven drifts
  • No shared services
New stack
  • modern web framework
  • proxy.ts hostname routing
  • managed Postgres
  • transactional email rails
  • Slack router + AI Gateway

What changed, with evidence

Design

Hostname routing makes a brand a config entry

proxy.ts maps each inbound domain to its brand: theme, nav, catalog, copy. Taylor Metal and Roseville RV share zero audience but share every line of infrastructure. Standing up brand number eight is a routing entry, a Neon branch, and a theme — not a project.

Before
Each brand meant another site to build, host, patch, and forget.
After
Seven brands ride one deploy; improvements land portfolio-wide instantly.
Retention

Branch-per-brand data isolation on Neon

Each brand's data lives on its own Neon branch — leads for the dumpster brand can never leak into the stove brand's queries, retention/deletion policies can differ per brand, and a migration can be rehearsed on one branch before touching the rest.

  • 7 Neon branches, one per brand
  • Drizzle schema shared; data planes isolated
Real-time push

Owned comms rails: SES + self-hosted VAPID push + a Slack router

Transactional email is shared SES; web push is self-hosted VAPID (no OneSignal-class vendor holding the subscriber list); and a Slack router fans ops events, inbound leads, and review alerts into per-brand channels so the right person sees the right brand's signal.

  • Self-hosted VAPID keypair — subscriber list is first-party data
  • Slack router: ops / leads / reviews per brand channel
  • Vercel AI Gateway fronts the LLM calls

While the owner sleeps.

Autonomous surfaces

The agent backbone keeps the brand earning after hours. The owner approves; the system runs.

  • Routes every lead to the right brand's Slack channel

    on each event

    Inbound leads, ops events, and review alerts fan out through the Slack router to per-brand channels the moment they land — seven brands, zero shared-inbox triage.

  • Pushes to subscribers without a push vendor

    on each send

    Self-hosted VAPID web push notifies brand subscribers directly — the subscriber list stays first-party, and no third-party vendor sits between a brand and its audience.

← All rebuilds

JP Taylor Group — seven brands run from one place instead of seven — zsty.us