Our Journey to Streamline a Complex Consumer Frontend

Six consumer products once meant six distinct frontends, each with its own repository, release process and team. As the portfolio grew, so did the cost of coordinating releases, maintaining a consistent player experience and changing more than one product at a time.

The separation gave teams autonomy, but cross-product changes required repeated integrations and releases. Coordination took days. Each boundary added cost and another place for the player experience to drift.

We set three goals:

• Move Faster: Reduce the time and effort required to release changes, enabling us to respond quickly to market demands and player feedback.
• Improve Product Consistency: Ensure a seamless and cohesive player experience across all products, leveraging shared components and design systems.
• Balance Risk: Minimize the risk of introducing bugs or breaking changes while maintaining the agility to innovate.

This journey has taken us through several architectural evolutions—from a fragmented, product-specific approach to a unified frontend app housed in a monorepo, and eventually to a decoupled backend/frontend architecture. Along the way, we’ve explored various strategies to improve both player and developer experiences, including the adoption of a robust design system.

Now, we stand on the brink of our next major step: moving to a single domain. For years, our products have been hosted across six different web sub-domains, which introduced inherent problems. Product switching was slow and cumbersome, and tracking player journeys across sub-domains was inconsistent, leading to fragmented data and a disjointed player experience. These challenges made it difficult to deliver a holistic, joined-up, and consistent experience for our players.

By consolidating our products under a single domain, we aim to eliminate these pain points. This transition, which will take place over the coming weeks and months, represents a significant milestone in our journey. A single domain will streamline releases, enhance the player experience, and reduce coordination overhead. It will also provide a foundation for future innovations as we continue to evolve our architecture to meet the needs of our players and business.

Single Domain: A Foundation for Improvement

The move to a single domain is the cornerstone of our efforts to streamline the frontend architecture. By consolidating our six sub-domains into one, we’ve addressed long-standing issues that impacted both players and developers. This change not only simplifies the technical landscape but also unlocks significant benefits across player experience, SEO, and developer efficiency.

Player Experience Improvements

The move to a single domain has been transformative for our players. Previously, navigating across multiple sub-domains was slow and disjointed, creating friction in the player journey. Switching between products often resulted in delays, broken tracking, and a lack of continuity. Now, with all products hosted on a single domain, players enjoy a seamless, fast, and consistent experience. Tracking is more accurate, enabling us to better understand player behavior and deliver personalized experiences. The holistic, joined-up approach ensures that players can move effortlessly between products, fostering greater engagement and satisfaction.

SEO and Domain Authority Benefits

Moving to a single domain also brings significant SEO (Search Engine Optimization) advantages. Previously, having six separate sub-domains diluted our domain authority, as search engines treated each sub-domain as a distinct entity. This fragmentation made it harder to rank competitively for key terms and reduced the overall visibility of our products.

By consolidating under a single domain, we’re able to consolidate our domain authority, making it stronger and more impactful. All inbound links, social shares, and engagement metrics now contribute to a single domain, boosting our search engine rankings and improving discoverability. Additionally, a unified domain simplifies our SEO strategy, allowing us to focus on optimizing one primary domain rather than spreading efforts across multiple sub-domains. This change not only enhances our organic search performance but also provides a better experience for players searching for our products online.

Design Systems: Consistency for Players and Developers

A key enabler of our journey has been the adoption of a unified design system. This system provides a shared library of components, patterns, and guidelines that ensure consistency across all products. For players, this means a cohesive experience—whether they’re using Product A or Product F, the look, feel, and behavior remain familiar and intuitive.

For developers, the design system has been a game-changer. Instead of reinventing the wheel for each product, teams can now leverage pre-built, reusable components that are thoroughly tested and documented. This not only speeds up development but also reduces the risk of inconsistencies and bugs. The design system fosters collaboration across teams, as everyone works from the same foundational elements, and it empowers developers to focus on building features that enhance the player experience rather than wrestling with UI inconsistencies.

Developer Experience Improvements

The transition to a unified architecture and single domain has also significantly improved the developer experience. Previously, developers worked in silos, focusing on individual products without visibility into the broader ecosystem. This often led to duplicated efforts, inconsistent implementations, and a lack of shared knowledge. Now, with a unified architecture, shared design system, and single domain, developers can work against the holistic experience. Collaboration across teams has become easier, redundancy has been reduced, and consistency across products is now the norm. Developers can focus on building features that enhance the entire player journey, rather than being confined to the constraints of a single product silo.

In this document, we outline the key steps in our journey, the lessons we've learned, and the trade-offs we've made. We also explore how different architectural approaches—monorepos, backend/frontend splits, and design systems—have impacted our ability to deliver value faster, maintain consistency, and manage risk. By sharing our experiences, we hope to provide insights for other organizations facing similar challenges and to inspire continued innovation in frontend architecture.

Cost Factors associated with a Unified Frontend App with 6 Products

Explanation for Unified Frontend App with 6 Products

1. Original:

• Each of the 6 products within the frontend app has its own repository or project, requiring changes to be integrated 6x.
• Each product requires a combined frontend and backend release (6x), leading to significant coordination overhead.
• 6 teams (one per product) are involved, leading to complex coordination challenges.
• Time Taken to Release: Days, due to the need for coordination and multiple releases.
• Overall Cost Factor: 216 (6 integrations × 6 releases × 6 days).

2. Monorepo:

• All 6 products are housed in a single repository for the unified frontend app, reducing integration complexity to once.
• However, each product still requires a combined frontend and backend release (6x), as the release procedure itself hasn't changed.
• 6 teams (one per product) are involved, but integration is simplified due to the monorepo.
• Time Taken to Release: Days, as the release procedure itself didn't change.
• Overall Cost Factor: 36 (1 integration × 6 releases × 6 days).

3. Monorepo & Backend/Frontend Split:

• The frontend and backend are decoupled, allowing the frontend to be released independently of the backend.
• Each product still requires a combined frontend and backend release (6x), but the frontend can be released independently in minutes.
• 6 teams (one per product) are involved, but the decoupling reduces coordination overhead for frontend releases.
• Time Taken to Release: Minutes for the frontend, as it can be released independently; no need for regulatory approval in most cases.
• Overall Cost Factor: 0.6 (1 integration × 6 releases × 0.1 days).

4. Monorepo, Backend/Frontend Split & Single Domain:

• The entire unified frontend app is in a single repository, and the frontend and backend are decoupled.
• The product now only needs to be released once, as the app is treated as a single domain.
• A single team handles the changes, minimizing coordination efforts.
• Time Taken to Release: Minutes for the frontend, as it can be released independently; no need for regulatory approval in most cases.
• Overall Cost Factor: 0.1(1 integration × 1 release × 0.1 days).

Microfrontends: The Next Step in Evolution?

• What Are Microfrontends?: Microfrontends extend the concept of microservices to the frontend, allowing different parts of a web application to be developed, deployed, and maintained independently by separate teams.
• Benefits:
  • Independent Releases: Teams can release their microfrontend independently, enabling faster iteration and reducing coordination overhead.
  • Team Autonomy: Each team can choose its own framework, tools, and development practices, fostering innovation and specialization.
  • Scalability: Microfrontends are well-suited for large, complex applications with multiple teams working in parallel.
• Drawbacks:
  • Framework Compatibility: Different microfrontends may use different frameworks (e.g., React, Angular, Vue), leading to potential compatibility issues and increased complexity in integration.
  • Performance Overhead: Loading multiple frameworks or libraries can increase page load times and reduce performance.
  • Consistency Challenges: Maintaining a consistent player experience and design system across microfrontends can be difficult without strict governance.
• Evolutionary Step:
  • Microfrontends represent the next step in the evolution of frontend architecture, building on the benefits of monorepos and backend/frontend splits.
  • They enable even greater independence and scalability but require careful planning and tooling to address compatibility and performance challenges.
  • Organizations should consider microfrontends when they have multiple teams working on distinct areas of the application and need to scale development efforts without sacrificing release agility.

Process and People Changes Required

• Technical Capabilities Are Not Enough: While the scenarios above highlight the technical advantages of a monorepo, backend/frontend split, and single-domain approach, these benefits cannot be fully realized without corresponding changes in processes and team dynamics.
• Process Changes:
  • Release Processes: Moving to a unified frontend app requires redefining release processes to accommodate independent frontend releases, automated testing, and continuous integration/continuous deployment (CI/CD) pipelines.
  • Coordination: Even with a monorepo, teams must establish clear communication and coordination mechanisms to avoid conflicts and ensure smooth integration of changes.
  • Regulatory Compliance: In industries like gaming, regulatory approvals may still be required for backend changes, necessitating a clear separation of frontend and backend release processes.
• People Changes:
  • Team Structure: Transitioning to a single team or reducing silos between product teams requires a cultural shift, encouraging collaboration and shared ownership of the unified app.
  • Skill Sets: Teams may need to upskill or adapt to new tools and workflows, such as monorepo management, CI/CD practices, and independent frontend deployment.
  • Mindset Shift: Moving from product-specific ownership to a unified app mindset requires buy-in from all stakeholders, including developers, product managers, and leadership.
• Change Management: Successfully adopting these technical capabilities requires a structured change management approach, including training, documentation, and iterative improvements to processes and workflows.
• Iterative Transition: Organizations may need to transition gradually, starting with a monorepo, then decoupling the backend and frontend, and finally moving to a single-domain approach, ensuring that processes and teams adapt at each step.

Key Considerations for Unified Frontend App

• Integration: In a unified app, changes to shared components or libraries benefit from being in a monorepo, as they only need to be integrated once.
• Releases: The frontend app can be released independently in minutes with a backend/frontend split, but backend releases might still be required depending on the nature of the change (e.g., API updates, new features, or bug fixes).
• Teams: Moving to a monorepo or single-domain approach encourages collaboration and reduces silos between product teams.
• Time Taken to Release: With a backend/frontend split, frontend releases can be completed in minutes, significantly reducing the time compared to the original and monorepo scenarios (which could take days).
• Overall Cost Factor: The cost factor decreases significantly as integration, releases, and time taken to release are streamlined, with the lowest cost in the Monorepo, Backend/Frontend Split & Single Domain scenario.