Lemonade’s disruptive approach continues into localization

A revolutionary insurance policy to satisfy everyone

Lemonade broke into the insurance market in 2016. It was a huge industry that matured over the years with well-established market giants and fundamental problems such as conflicts of interest and a lack of trust between insured parties and insurance companies.

According to Lemonade, “Once you know how things are done, you can't unknow what you already know.” Thus, instead of building another insurance company and following the status quo of the industry, they tried to focus on solving the core problem of distrust in the sector. They brainstormed how to change that, and apply behavioral economics and statistics to disrupt the market. 

It’s been a long and challenging road, but Lemonade is thriving. Now it’s an AI-enabled full-stack insurance carrier featuring numerous products with a redefined insurance business model to remove the inherent conflict of interest and resolve trust issues. 

To combat the perception that insurance companies resist paying their customers’ claims, Lemonade charges a flat fee and doesn’t benefit from excess gains, which are routed to non-profits selected by its community during its annual Giveback. 

After a successful launch in the US, Lemonade started to expand to other markets, and soon realized they could significantly accelerate growth through localization. There were two main triggers for this.

Challenge 1: maintaining a streamlined and error-free process 

According to Dor, Lemonade's previous translation management system (TMS) was set up in a way that didn’t have a versioning system. All keys and translations were stored and edited in a shared environment by multiple developers, making it difficult for them to track and pick their own changes for further testing. 
 

“When we started, we had a different translation system that was enough for Lemonade’s needs at the time. We had multiple issues working with it.”

It is quite common that a developer is working on their own feature in its own branch/version of the app. Lemonade aimed to apply the same approach to localization, making developers responsible for testing their own changes on the localized features. Since all key and text changes went into a shared version pool of translations, the tech team looked for a clear way to keep track of changes made by various teammates and make testing easier.

“The main issue was that we had a lot of developers working on translation features at the same time over the same source of truth, meaning that they had to cherry-pick the changes which were related to the features to test their own changes. And that was not scalable at all.” Dor recalls.

Another goal was to protect the code and ensure that it remained as clean as possible. There can be localized feature versions in development that never make it to production. 

“We also wanted to keep the code clean and avoid redundant keys that were not being used in the app. They can still be stored in Lokalise project branches, but not in our code.” 

Challenge 2: bottlenecks from working with text

Lemonade soon realized they wanted to flag these localization issues faster. Each developer has access to their own staging environment, where they can test features and localization. With the previous TMS and approach to localization in order to see a change, a deployment cycle of approximately 2.5 minutes was required. It might not seem like a huge issue, but if you multiply it by the number of releases/changes made each day, and multiply it by the number of developers, you would quickly realize why working with text became the largest bottleneck in Lemonade’s high-pace implementation flow.

For example, when a German-speaking content creator and a QA team member requested a change for a specific feature, the team had to:

• Implement the change in the TMS
• Change the values of the feature
• Pull them to the code
• Commit to Git
• Wait for deployment cycles of 2.5 minutes for each change before implementation
• Test the results and repeat the process (if further change was needed)

“That’s the other issue we went through with our first integration system in Germany: working with text became one of our biggest bottlenecks.”

Lokalise steps in with translation branches

Improving process management for feature-based development while speeding up translation processes was an ambitious challenge for Lemonade. They were intent on making processes smoother, knowing what they wanted to achieve, but without knowing exactly how at that step. And they started to brainstorm and research options for translation management systems (TMS). 
 

“Back then, we knew we wanted to do things better, and I started to look for a different kind of TMS. Although I wasn’t exactly sure what I was looking for, I knew that I wanted to make changes in the staging level before publishing. When I learned about branching in Lokalise, I immediately knew that was what we needed.” says Dor.

Creating specific translation branches for each developer meant that they would be able to control translation changes needed for the scope of those features. Therefore, parallel translations wouldn’t affect each other anymore, with the developer pulling only their own changes to the source code afterward.

“The new workflow we wanted to adopt was that any translation changes needed for each code feature would happen within their translation branch. Therefore, since each developer had their own Lokalise branch with translations and its own staging branch for testing, all the changes remained isolated until pulling them into the code.”

Project branching was a relatively new Lokalise feature back in 2020, allowing users to manage several versions of translations. Lemonade soon realized that it was not working in the same way as branching in code repositories does. Therefore, their team started to look into how they could benefit from the ability to version translations in Lokalise and combine that with Lokalise's developer features, including a flexible API and webhooks.

 This has helped to resolve both challenges; developers working on separate branches independently, having the source code clean, and improving the turnaround time for working with text.

Full integration for seamless changes 

Fortunately, Lemonade found their ideal solution in Lokalise. “We wanted to come up with a solution that provided us with the ability to implement dynamic translation changes. That would mean strings updated on each Lokalise branch would be instantly updated in a testing environment with the capacity to test them directly in that branch.”

The solution was to implement a translation service (TS) on Lemonade’s end, which would act as a proxy for Lokalise and collect all the changes happening in every Lokalise branch with the help of the API and webhooks. This has involved proper alignment internally, making sure developers work on features in parallel, and unifying the way the content is created and updated. The Lokalise API was flexible enough to let Lemonade collect every change made, identifying the branch it’s coming from so that our service could replicate it in the respective local branch (removing deployment times). 

Once the developer is satisfied with the changes, he or she runs a command that merges the branch both into a master in production and into a master on Lokalise, committing the new changes.

Regarding Lemonade’s choice to proceed with a custom integration, Dor shared the following: 

“I wanted to have different bundles of translations, so in case some features reverted later in production, they could immediately merge and update into the TS. Then I realized that I didn’t need to keep the entire bundle of translations per branch as I only needed the latest changes. Our code is the source of truth, and even after the branch is reverted in production, we don’t require a complete parity between Lokalise and the code for all branches. It’s a change that matters for us.”