← Back to work
Case study · Multi-brand architecture

Supporting two brands in Rails

After our client’s business was acquired, we adapted the existing Rails application to serve both brands. At the same time, we started moving parts of the frontend from AngularJS to React.

Focus
Multi-brand architecture
Platform
Ruby on Rails · React · AngularJS
Delivery
Incremental releases with feature switches
Existing brand Existing domain

Established identity & customer journeys

New brand New domain

New identity & integrations

One Rails application

Shared domain detection

Hostname → brand configuration → routing constraints

Routes & APIs

Brand-specific routes and integrations

Layouts & frontend

Shared components, distinct styles and behaviour

Release controls

Feature switches with Rollout

Conceptual architecture · Two branded experiences within a shared application
01 The context

What needed to change

Following the acquisition of our client’s business, the existing application needed to serve both the original brand and the new one.

The transition introduced new domains, API integrations, routes, and visual designs. Each domain needed its own branding and behaviour, while existing customer journeys continued to work.

Alongside this transition, we also began migrating selected frontend journeys from AngularJS to React. The challenge was to evolve both experiences within a single Rails application.

02 The approach

How we handled each brand

01 / Identify

Detecting the brand

We separated brand-specific configuration and introduced a shared domain detection module. It identified the brand from the incoming request’s hostname, giving the application a consistent way to select the appropriate experience.

02 / Route

Separating the routes

Rails routing constraints used that detection logic with separate route files for each brand. The same application—and, where needed, the same URL path—could serve different behaviour depending on the requested domain.

03 / Adapt

Selecting layouts and components

Controllers and views selected layouts and JavaScript entry points, passing configuration into React through the page. Shared components adapted their presentation and behaviour, with brand-specific styling and components where required.

03 Migration & rollout

Migrating and releasing the changes

React alongside AngularJS

We introduced React into selected journeys while retaining AngularJS elsewhere. This allowed frontend modernisation to progress incrementally alongside the branding work.

Deploy ahead of activation

We divided the work across multiple releases and used Rollout feature switches to control activation. Changes could be deployed ahead of launch, enabled in line with marketing requirements, and disabled if problems emerged.

04 The outcome

What we ended up with

Both brands could run in the same application, with their own routes, layouts, and behaviour.

Existing customer journeys continued alongside the new brand, while selected journeys moved to React and releases could be activated independently of deployment.

05 Technology & delivery

Technologies used

Backend
Ruby, Ruby on Rails
Frontend
React, JavaScript, AngularJS (legacy), HTML/ERB, CSS/Sass
API layer
GraphQL, REST APIs
Feature management
Rollout
Infrastructure
AWS
Delivery and project management
Git, Azure DevOps
← Back to work