Case study Swan's journey to implement feature flags with Tggl

Who is Swan?

Swan is a rapidly growing fintech company offering Banking-as-a-Service solutions. Swan is at the forefront of innovation, providing scalable and reliable financial infrastructure to a wide range of clients. As Swan expanded, they recognized the need to better manage feature releases across their products to remain agile and reduce deployment bottlenecks. This led them to adopt feature flags using Tggl.

Swan is a registered electronic money institution and is regulated by ACPR. As such, they operate under strict compliance standards and are committed to security at all stages of product development and beyond. In addition, they enforce rigorous production stability controls, including the four-eyes principle, which ensures that no feature goes live without thorough review and approval. These necessary precautions added extra steps to anything which might result in changing their platform behavior (e.g. feature activation, data maintenance, code deployment, etc), making the adoption of feature flags essential for maintaining both agility and compliance.

Challenges

Before adopting Tggl, Swan managed feature flags with environment variables. While effective at first, this approach became a significant burden as the company scaled.

Engineering teams were caught in low-value tasks, such as manually testing and deploying new features, rather than focusing on high-impact work. Additionally, non-technical teams like product and QA were dependent on engineering to manage feature releases, which delayed product rollouts.

We realized that our product team wasn’t autonomous when it came to feature releases. Everything had to go through engineering, which slowed us down. The system was simply not scalable.

Jeremy, Engineering Director @ Swan

At a pivotal point, Swan decided to evaluate their internal processes and explore solutions that could help them regain agility, increase deployment frequency, and reduce reliance on manual testing.

The turning point: Choosing Tggl

The turning point came when Swan began measuring the organizational efficiency of their engineering department. One glaring issue was the dependency on extensive testing and validation before deploying new versions of their services. This led the team to evaluate feature flag providers to increase their release frequency—a key DORA metric.

Swan initially considered building their own solution in-house. However, after drafting a list of requirements and realizing the complexity of maintaining a system at scale, they decided to partner with an external provider.

Tggl was chosen for its ability to support both technical and non-technical teams, offering advanced release management features. This flexibility enabled Swan to onboard their developers, product managers, and QA engineers—quickly, creating a unified approach to feature management across the company.

Implementation process

Swan split the process into three distinct phases:

1. Initial discovery: Swan gathered input from technical and non-technical teams—product, QA, and design—to ensure the solution met the organization’s diverse needs. After evaluating several providers, they selected Tggl for its comprehensive features and seamless integration.

2. Proof of Concept (POC): Between October and December 2023, Swan ran a POC with two teams. The initial plan was to start with one team, but enthusiasm was so high that they quickly expanded the POC. Swan developed a NestJS module to integrate Tggl into their existing infrastructure and kept the process lean to gather feedback quickly.

   "The teams were eager to try it out, and within a week, everyone adopted it!" Jeremy recalled. The success of the POC gave Swan the confidence to roll out Tggl more widely.

3. Full deployment: From January to March 2024, Tggl was rolled out to all squads across the organization. With swift adoption, Swan formalized their processes with two key documents: the Feature Flag Practical Guide and Feature Release Management Process, ensuring scalability and consistency.

Technical implementation

Swan’s integration of Tggl focused on performance, scalability, and ensuring minimal disruptions during feature releases. Key to this was their use of local caches and a Tggl Proxy.

• Tggl Proxy: Swan used a local Tggl Proxy within their infrastructure to reduce reliance on the Tggl REST API. This proxy also acted as a fallback in case of any external service unavailability.
• Pod-specific caching: Each application pod maintained its own local cache of feature flag conditions, ensuring that evaluations were fast and efficient. The cache was refreshed every second, minimizing system load during complex evaluations like GraphQL N+1 queries.
• Hardcoded fallbacks: In case the cache wasn’t available, hardcoded fallbacks ensured that the system could always respond with predefined values even under the worst-case scenarios.

The use of local caches and fallback mechanisms allowed us to handle any potential unavailability of Tggl’s API. It also kept the performance stable, even during periods of high load.

Testing and release process

Testing was a crucial part of Swan’s process. The team employed rigorous unit and integration testing, as well as end to end testing before deploying feature flags to production. By injecting Tggl’s Typescript implementation into their NestJS applications, Swan ensured that all components requiring feature flag capabilities were thoroughly tested. This approach provided confidence that features were production-ready.

Swan’s release process also incorporated best practices, such as:

• Feature flag lifecycle management: Each feature flag was carefully documented with its purpose and expected lifespan, ensuring clarity and preventing the buildup of technical debt.

• Ownership and tagging: Ownership of feature flags was strictly enforced to ensure only the responsible squad could modify them, maintaining accountability within the team.

Key outcomes

Jeremy shared that Swan’s goal was to meet the DORA metrics of a high-performing organization.

Our objective was to deploy more than twice a week in production. This wasn’t the case before implementing Tggl. We achieved this goal in February 2024, just months after adopting Tggl, and it was a game changer. Since Q1 2024, our deployment frequency has doubled, and Tggl has played a significant role in this success, although not the only factor.

Jeremy, Engineering Director @ Swan

By enabling non-technical teams to manage feature releases independently, Swan saw marked improvements in several areas:

• Increased deployment frequency: Swan doubled their deployment frequency after implementing Tggl.
• Faster testing cycles: Manual testing was reduced, freeing up engineering resources for higher-impact tasks.

Collaboration with Tggl

One of the key reasons Swan’s implementation was so successful was Tggl’s responsiveness to feedback. Throughout the process, Tggl worked closely with Swan, adjusting to their unique needs.

For example, Swan played a critical role in the development of Tggl’s Reviews feature, which allows for review-based approval before activating feature flags in production.

Your responsiveness in addressing our feedback, whether it was a bug or a critical feature request, made the process smoother and more customized to our needs.

Jeremy’s recommendations for companies implementing feature flags

Based on Swan’s experience, Jeremy shared several key recommendations for companies looking to implement feature flags effectively:

1. Start small: Begin with a few key teams and conduct a POC before scaling across the entire organization. This allows teams to get familiar with the tool without overwhelming the process.

2. Engage all stakeholders: Don’t limit feature flag implementation to the engineering teams. Involve product, QA, and other non-technical teams to ensure everyone’s needs are considered.

3. Maintain a low count of active feature flags: Avoid overloading your system with too many active flags. Each feature flag adds complexity, so ensure you have a process for regularly removing unused flags.

4. Document & track everything: Every feature flag should be documented with its purpose, expected lifespan, and owner. Tggl’s feature flag description field is an excellent place for this.

5. Collaborate with your provider: Choose a feature flag provider that is responsive to your feedback and willing to partner with you. A strong partnership can help address challenges and adapt the tool to fit your unique use case.

Conclusion

Swan’s journey with Tggl demonstrates the profound impact of feature flags on agility, deployment speed, and product stability. By partnering with Tggl, Swan transformed their release process, doubled their deployment frequency, and empowered both technical and non-technical teams to manage feature releases independently.

The combination of a flexible feature flag tool and a stringent approach to compliance has enabled Swan to scale effectively and maintain their high standards as a regulated fintech leader.