Meet PLG Expansion — the team that turns “I didn’t know freee could do that” into “oh wow.”

IT STARTS WITH A USER WHO ALMOST GIVES UP

Picture this: someone logs into their freee dashboard for the fifth time this week, manually re-entering the same accounting data they entered last week, and the week before that. They don’t know there’s a feature that would automate all of it. Nobody told them. The button is buried three clicks deep, or it doesn’t exist on their screen at all.

Multiply that moment by thousands of users, across dozens of products, every single day. Missed features. Missed upgrades. Missed “wow” moments that quietly cost people time, and freee a chance to actually help them.

That gap — between what freee can do and what users know freee can do — is the entire reason our team exists.

 

MEET THE TEAM CLOSING THAT GAP

We’re PLG Expansion: Product-Led Growth. Our job isn’t to build flashy new features from scratch — it’s to make sure the right feature finds the right user at the right moment. A banner that shows up exactly when someone hits a wall. A product hub that quietly connects the dots across freee’s ecosystem. An onboarding flow that doesn’t let people get stuck in the first place.

What does PLG mean to its members in 3 words?

The team behind this is small but deliberately cross-functional:

• Developers who jump between different codebases and environments on a regular basis
• QAs who are constantly learning and testing workflows they’ve never seen before
• PdMs who realign with a new product team almost every sprint

It’s a fast-paced, no-two-weeks-are-the-same kind of environment. And that variety is the point — for us, “Product-Led Growth” isn’t just about growing the product. It’s about growing as a team, sprint after sprint.

 

Here’s a real example of what that looks like when things get technically messy.

 

THE CHALLENGE: A “SIMPLE” BANNER THAT WASN’T SIMPLE AT ALL

Last quarter, we got a straightforward-sounding task: show a random marketing banner on a product’s homepage, pulled from a pool of banners, each with its own display conditions.

The UI part? Easy. The logic behind it? Not so much.

Some of those display conditions depended on data spread across multiple tables, which meant running heavy, resource-hungry database queries just to figure out which banner to show.

We tried the obvious fix first: check the database every time the page loads.

The homepage slowed down by 1 to 2 seconds.

For context — that’s an eternity in page-load terms, and it was happening on every single visit. Not acceptable. Back to the drawing board.

 

FINDING THE RIGHT ARCHITECTURE

We put four options on the table:

1. Caching
2. An aggregated table of conditions
3. Optimizing the SQL with better indexes
4. Asynchronous evaluation and fetching

We landed on combining options 2 and 4.

First, we pre-aggregated the data. We leaned on an internal microservice called Octopus, built specifically to collect and centralize marketing data. Octopus talks to our main app over gRPC and does the heavy lifting ahead of time — aggregating everything a banner condition might need, so the app never has to run a multi-table query at render time. It just asks Octopus, “is this condition met?” and gets a fast answer.

Second, we split the logic and moved it off the critical path. Simple, lightweight conditions still ran as quick database checks. Complex, data-heavy conditions went through Octopus. And critically, the entire evaluation was moved to run asynchronously in the background — so the homepage could render immediately without waiting on any of it.

 

THE PAYOFF

The banner feature shipped. Homepage load times barely moved. The system scales cleanly as more banners and conditions get added.

But the real win was how it came together: our developers built the architecture, our QA team was the one who actually caught the 1-2 second slowdown during testing before it ever reached users, and our PdM adjusted the timeline to give the fix the room it needed instead of forcing a rushed patch. No single person solved this — the team did.

 

WHY WE DO THIS

Every friction point a user hits is really just an unanswered question: “Wait, can freee already do this for me?” Our job is to make sure the answer finds them before they give up looking.

As freee’s ecosystem keeps growing, PLG Expansion will keep building the quiet infrastructure — the banners, the hubs, the onboarding nudges — that turn those moments of friction into moments of “oh, nice.” For our users, and for the team building it.

“Smooth seas do not make skillful sailors.”

— African Proverb