DEV Community

Dynamite Technology
Dynamite Technology

Posted on

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

#architecture #javascript #react #saas


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 />
}
Enter fullscreen mode Exit fullscreen mode

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:

  1. Hexagonal Architecture — Business logic stays isolated from external dependencies
  2. Registry Pattern — Dynamic component and action resolution without conditionals
  3. Plugin Architecture — Brand-specific code lives in isolated plugin modules
  4. 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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Our middleware extracts the brand name:

const brand = hostname.split(".")[0]
Enter fullscreen mode Exit fullscreen mode

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)
Enter fullscreen mode Exit fullscreen mode

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)
Enter fullscreen mode Exit fullscreen mode

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 (...)
Enter fullscreen mode Exit fullscreen mode

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.)
Enter fullscreen mode Exit fullscreen mode

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
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

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
}
Enter fullscreen mode Exit fullscreen mode

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)
Enter fullscreen mode Exit fullscreen mode

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)
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (0)