Scaling a Multi-Brand SaaS Platform Without Losing Your Mind: How We Built It

Dynamite Technology — Fri, 15 May 2026 18:50:22 +0000

You're the architect of a SaaS platform. Your sales team just closed three major clients—each with their own branding requirements, custom workflows, and backend integrations. Your CTO asks: "Can we make this work without spinning up separate deployments?"

Your answer used to be "maybe," and it would involve a lot of if (brand === "...") statements scattered across your codebase.

We've been there. And we found a better way.

The Nightmare: Conditional Architecture Hell

When we first started supporting multiple brands, our approach was... let's call it "direct."

if (brand === "dynamite") {
  return <DynamiteCard />
}

if (brand === "restaurant") {
  return <RestaurantCard />
}

if (brand === "pharmacy") {
  return <PharmacyCard />
}

The problems started immediately:

Impossible to maintain: Every new feature meant touching dozens of conditional branches
Tight coupling: A change for one client could break another
Onboarding nightmare: Adding the fifth brand meant rewriting half the application
Dangerous to modify: You couldn't refactor anything without fear

We called it Conditional Architecture Hell, and every team that's scaled a multi-tenant SaaS has lived through it.

The real question wasn't "can we support multiple brands?" It was "can we support them elegantly?"

The Answer: A Hybrid Architecture

Instead of building separate systems for each brand, we designed a single platform that could bend to different requirements without breaking.

Our solution combines four key patterns:

Hexagonal Architecture — Business logic stays isolated from external dependencies
Registry Pattern — Dynamic component and action resolution without conditionals
Plugin Architecture — Brand-specific code lives in isolated plugin modules
Adapter Pattern — Different backends speak a common language (Unified DTOs)

This gave us one codebase, one deployment, and infinite flexibility.

How It Works: The 30,000-Foot View

Here's the basic flow:

Browser
   ↓
Next.js Frontend (Single App)
   ↓
Brand Plugin Layer (Dynamic Resolution)
   ↓
Backend API Gateway
   ↓
Brand Adapter Factory (Normalize Everything)
   ↓
Database / External APIs

Each layer is designed to solve one specific problem. Let's break it down.

Part 1: Frontend — The Registry Pattern

The frontend is the first place where the magic happens. Instead of hardcoding which component belongs to which brand, we use a registry.

Brand Detection via Subdomains

We identify tenants through subdomains:

dynamite.domain.com
restaurant.domain.com
pharmacy.domain.com

Our middleware extracts the brand name:

const brand = hostname.split(".")[0]

This becomes the tenant context for the entire request.

Components Are Registered, Not Hardcoded

Instead of conditionals, we register components by brand:

registerRecordCard("dynamite", DynamiteCard)
registerRecordCard("restaurant", RestaurantCard)
registerMenuAction("Live Track", LiveTrackAction)
registerMenuAction("Start Delivery", StartDeliveryAction)

When the frontend needs to render something, it doesn't check if brand === X. It just asks the registry:

const CardComponent = getRecordCard(brand)
const ActionComponents = getMenuActions(brand)

Why This Pattern Changed Everything

The registry pattern eliminated:

Problem	Solution
Endless conditionals	Dynamic resolution
Hard to onboard new clients	Register and go
Risky refactoring	Isolated logic
Can't scale beyond 10 brands	Supports unlimited brands

This single decision became one of the most important architectural choices we made.

Part 2: Backend — Hexagonal Architecture

The frontend was half the battle. The backend was harder.

Every brand had:

Different database schemas
Different API endpoints
Different query logic
Different transformation rules
Different business workflows

A typical query might look completely different for each tenant:

// DynamiteAdapter
SELECT * FROM order_tracking WHERE status = 'active'

// RestaurantAdapter
SELECT * FROM delivery_orders WHERE completed_at IS NULL

// DataneralAdapter
SELECT * FROM prescription_orders WHERE fulfillment_status IN (...)

We couldn't just "configure" our way out of this. We needed a way to let each brand implement its own data fetching logic, but have everything speak the same language downstream.

Enter Hexagonal Architecture.

The Principle: Business Logic Shouldn't Know About Persistence

In hexagonal architecture, your core business logic sits in the center and communicates with the outside world through ports (interfaces). The actual database, APIs, and external services are adapters that implement those ports.

Domain (Pure Business Logic)
   ↓
Application Services
   ↓
Ports (Interfaces)
   ↓
Adapters (Database, APIs, etc.)

This means:

Your business logic doesn't care if data comes from PostgreSQL, MongoDB, or an external ERP
You can swap implementations without touching core logic
Each brand can fetch data however it needs, as long as it conforms to the port interface

Brand Adapters in Practice

Each tenant gets its own adapter:

class DynamiteRecordAdapter {
  async getRecords() {
    return prisma.$queryRaw`
      SELECT * FROM dynamite_orders 
      WHERE status NOT IN ('completed', 'cancelled')
    `
  }

  async transformToUnified(record) {
    return {
      card_type: "BOOKING",
      products: record.items,
      order_total_amount: record.total
    }
  }
}

class PharmacyRecordAdapter {
  async getRecords() {
    return prisma.$queryRaw`
      SELECT * FROM prescriptions 
      WHERE fulfillment_status = 'pending'
    `
  }

  async transformToUnified(record) {
    return {
      card_type: "PRESCRIPTION",
      products: record.medications,
      order_total_amount: record.total_charge
    }
  }
}

Each adapter:

Fetches data its own way ✓
Transforms data its own way ✓
Returns a unified contract ✓

The Normalization Layer: The Unsung Hero

This became the most important backend layer. Everything flowing from the adapters gets normalized into Unified DTOs:

interface UnifiedRecord {
  card_type: "BOOKING" | "BILLING" | "PRESCRIPTION"
  products: Product[]
  order_total_amount: number
  timeline?: Activity[]
  customer: Customer
}

No matter where the data came from or what it looked like originally, the frontend sees the same structure:

Different Schemas
        ↓
Normalization Layer
        ↓
Unified DTO
        ↓
Frontend (No surprises)

This single layer eliminated dozens of rendering bugs and made the frontend dramatically simpler.

Part 3: Configuration vs. Code — The Hybrid Model

One of our biggest mistakes early on was trying to make everything configurable.

Some clients needed completely custom booking flows. Others needed live tracking integrations. Some wanted QR-code-based workflows. Making all of that configuration-driven would create an unmaintainable abstraction layer.

Instead, we split the problem:

What We Make Configurable

Simple, declarative stuff:

Themes and branding
Menu structure and visibility
Feature flags
Permissions and roles
Invoice settings
Module visibility

These are declarative and safe to change without touching code.

What Stays Plugin-Based

Complex, behavioral stuff:

Custom workflows
Advanced UI interactions
Complex business logic
Brand-specific experiences
Custom integrations

For these, we let engineers write code inside isolated plugin modules.

This hybrid approach gave us the best of both worlds: flexibility for simple customizations and the power of code for complex ones.

The Final Architecture

By the end, we had built:

Shared SaaS Core (Common functionality)
   +
Registry Pattern (Dynamic UI resolution)
   +
Plugin Adapters (Brand-specific code in isolation)
   +
Hexagonal Backend (Business logic stays pure)
   +
Unified DTO Contracts (All backends speak the same language)

What This Unlocked

With this architecture in place, we were able to:

✅ Onboard new brands faster — No code duplication, no re-architecting

✅ Update the shared core safely — Changes don't ripple across brands

✅ Support 10x more features — Plugin system let brands innovate independently

✅ Reduce bugs dramatically — Isolated plugin code, shared testing, unified contracts

✅ Scale the team — Junior engineers could work on brand plugins without touching core

✅ Move faster — No more "this change might break brand X" conversations

The Real Lesson

The real lesson wasn't about any single pattern. It was about thoughtful separation of concerns.

The registry pattern solved UI composition. Hexagonal architecture solved data access. Plugin architecture solved deployment scale. DTOs solved the integration seams.

No single pattern would have worked alone. But together, they created something greater than the sum of their parts.

If you're building a multi-tenant SaaS and you're drowning in if (brand === statements, know this: there's a better way. It takes more upfront thinking, but it pays for itself a hundred times over as you scale.

Have you built a multi-brand platform? What patterns worked for you? Share your thoughts in the comments below.

DEV Community: Dynamite Technology