Stopping someone from simply letting you go takes consistent effort. People stay when they remember that you serve a purpose in their lives. But people often forget. People move on.

Not PLG-Platform.

As freee’s development team dedicated to user retention, we work to keep users holding on to the products they use. We champion the company’s product-led growth (PLG) approach, letting the products we support speak for themselves. Figuratively, this means allowing users to experience firsthand the value of our enterprise resource planning (ERP) software solutions and encouraging them to explore more. But we also mean products speaking for themselves quite literally. Part of our job is to make our solutions plug themselves into users’ experiences through pop-ups.

 

 

Pop-ups, as we refer to them, are little rectangles containing images and text that appear over or alongside a page’s content. They offer features users may have forgotten or may not know about. Typically, these run for a few weeks before disappearing permanently.

 

 

Creating them, however, goes beyond putting together visual displays. We need to consider when and where they appear, and monitor how users interact with them. Multiple professionals also need to get involved. In PLG-Platform alone, a pop-up passes through a product development manager, developers, and quality assurance (QA) engineers.

 

 

Every pop-up request means a new requirement document, a new ticket, a new review, and a new QA cycle—even for minor adjustments. That’s a lot of work for something that can take days to develop but will likely remain relevant for only a few weeks.

It is critical, then, that the development process for these pop-ups becomes smoother. Their deployment needs to be swifter. Their elements are to be substitutable.

Basically, what freee needs is to be freer to plug.

 

How to be freer?

PLG-Platform proposed freee-plg.

The idea is simple: build a centralized pop-up factory. Give it all the necessary assets and information. Build the pop-up, embed a portal in a consuming service, and then insert the pop-up into that portal.

In more technical terms, freee-plg is an internal promotional content microservice that allows other services within the freee software ecosystem to retrieve and use ready-made components.

With this vision in mind, the team began building.

 

To Be Freer by Establishing Standards

The first step was to standardize the assets and information needed to create pop-ups.

The team reflected on how we regularly put pop-ups together. We asked ourselves: What details do we always require from our product development manager? What HTML elements do our QA engineers generally expect? How do our developers traditionally translate these requirements into Ruby on Rails and React code?

We held several team retrospectives to answer these questions. We confronted one another about how we did things: what went well, what went wrong, and what we could improve. Fingers were pointed—never at anyone, but only at ideas scrawled across company whiteboards and texts typed in shared online documents.

Those shared insights became the reusable standards behind freee-plg’s YAML configuration files. One file now serves as a blueprint for creating a pop-up, while another defines how we package multiple pop-ups together.

With these standards in place, we could make pop-up creation more consistent and avoid starting from scratch with every request.

 

To Be Freer by Learning When to Let Go

Building the pop-up factory became our next business.

We initially built freee-plg by piggybacking on the preexisting freee-product-hub service.

This approach kept development costs low. Setting up connections among services was no longer a concern for our developers. QA engineers had already established how to test the tried-and-true service. The product hub also housed actual product data, so storing promotional data there seemed like a smart move.

freee-product-hub was essentially a template begging to be used—and for a team accustomed to fast-paced initiatives, it was only natural to give in.

That setup worked during the early stages. But as freee-plg continued to grow, the product hub eventually needed room to breathe.

We eventually realized that promotional data would grow much faster than product data. Every new pop-up meant more code added to the existing codebase. It also meant more network calls that had little to do with the product hub’s primary purpose.

In other words, a service designed solely to handle product information was becoming increasingly difficult to maintain. It also slowed users’ sessions by handling unnecessary requests.

We realized that keeping both services together would only create more problems as freee-plg continued to grow. So, even if it meant more work, we didn’t hesitate to separate the two.

freee-plg let freee-product-hub go.

 

To Be Freer by Having Options

With freee-plg now operating independently, we also needed to figure out how portal embedding and pop-up insertion would work.

Initially, we integrated pop-ups using inline frames, or iframes. For the uninitiated, these are native HTML elements that allow a page to display content from another source.

Arguably, this was the most basic way to embed content. In our developers’ minds, the simpler the implementation, the easier the integration—and the sooner we could deliver more to users.

But not everything works out the way we want it to.

When our QA engineers tested the approach, its performance simply wasn’t on par with what was already in production. Pop-ups took too long to load, and network tools reported higher memory usage. Ultimately, users experienced the lag.

Our developers also found authoring with inline frames painful. For example, reusable modals from a separate package required modifications just to accommodate the approach. Instead of focusing solely on translating requirements into code, we had to develop additional solutions to make everything work together.

We realized that fixing these issues would take more effort than the approach was worth.

And so, the team looked for alternatives. If the most basic approach wasn’t working, perhaps script injection would do the trick.

And sure, at first, it did. Script injection addressed some of the performance issues we encountered with inline frames. But the method eventually proved to be a mismatch, too.

It still created a significant maintenance burden. Our developers needed to carefully manage and consolidate code across multiple services. Changes in one service could easily affect another. A seemingly harmless styling adjustment, such as changing a pop-up’s text color, could unintentionally change the page’s text color, too.

We could have compromised, but we never settle for less.

So we continued exploring other options until we found a better fit: web components with shadow DOM.

Web components allowed us to create reusable pop-up elements, while shadow DOM provided an isolated environment for their structure and styling. This meant that pop-ups could function independently without accidentally interfering with the pages displaying them.

This approach improved freee-plg’s performance and made its components more independent of the services using them.

Now, consuming services only need to be involved during the initial setup. Once a pop-up’s revisions are ready, they automatically become available on the consuming page. Users can see the latest version simply by refreshing. Even our product development manager can now tweak pop-up contents without needing our developers. He only needs to replace the text in a served file and save it.

With this approach, we finally achieved what we had envisioned: a centralized pop-up factory that makes creating, updating, and deploying promotional content much easier.

 

Are We Now Freer?

It’s been a year since the microservice’s inception. After everything, freee-plg has helped freee save time on pop-up production.

The most measurable improvement is the development timeline. What previously took weeks of development and testing can now be completed in an average of two to three days. That’s a significant reduction in turnaround time for promotional content that may only remain relevant for a few weeks.

Since its implementation, freee-plg has also supported the creation of countless banners and modals across multiple services to promote the company’s product catalog. With reusable components, standardized configurations, and a more independent deployment process, the team can now produce and update these promotional materials with considerably less effort.

For the foreseeable future, PLG-Platform will continue striving to stop users from letting freee go. New pop-ups will be produced through freee-plg, while further improvements to the microservice will help speed up production even more.

Along these efforts, the team will continue improving how the product hub presents the details of the products we promote. Reporting retention-related data will also remain among our responsibilities.

All of these we will do so people no longer easily forget.

We hope that, by reminding people of the value our products bring, we can encourage them to stay longer with freee. Though their memories may fade and their priorities may shift, may they not move on from us.

And may that happen because people like us consistently and tirelessly remind them why they made the right choice to be with freee—one plugged pop-up at a time.