Consolidating Philo's Experience

System Architecture & Strategic Framework

Work

About

Stack

Monetization was getting messy fast. Too many entry points, inconsistent upgrade flows, and experiments stepping on each other. I stopped thinking in screens and built a system that handled upgrade logic across the entire product. Now the team can test and ship without breaking the experience every time.

The Shift That Broke Everything

Philo used to be simple. One subscription. One path. Easy to explain. Then things changed. We introduced free entry points, bundles, and different ways to access the product. Good for the business, but it quietly broke the experience.


Upgrade paths got messy. Messaging got inconsistent. Users were bouncing between states without really understanding what they were getting or why they should pay. We didn’t just have a UX problem. We had a system problem.

What Was Actually Going Wrong

If you zoomed out, everything looked fine. But when you looked closer, it was fragmented. Upgrade flows depended on where you entered. Messaging changed depending on the surface. Free, trial, and paid states didn’t feel connected. And every new experiment risked stepping on something else.


Worst part, we started seeing cannibalization. Changes meant to drive growth were hurting our core subscription funnel. So the question wasn’t “how do we improve this screen.” It was “how do we stop this from breaking every time we touch it.”

Starting With a System, Not a Screen

I owned the design side of fixing this. Not just screens. The system behind it. That meant:


  • Thinking through every credential state across the lifecycle
  • Designing upgrade entry points across web, mobile, and TV
  • Working with Growth and PBS to align experiments with business goals
  • Running and learning from A B tests
  • Making sure whatever we built could scale without constant redesigns


This wasn’t a one feature problem. It was infrastructure.

Testing Our Assumptions (and Breaking Some Things)

Before designing anything new, I mapped the entire lifecycle. Free. Trial. Paid. Every state, every transition, every edge case. From there I defined:

  • Where upgrade triggers should exist
  • When users should see them
  • What context they should have before hitting them


This became the foundation for everything else. Instead of reacting to problems, we had a model we could build on.

Turning Learnings Into Product Infrastructure

We ran a lot of experiments. Some of them worked. Some of them didn’t. We tested removing the 10 foot landing page. We tested new upgrade entry points. We tested embedding upgrade education directly into the product instead of relying on external flows. What we learned pretty quickly:


  • If you push upgrades too early, you hurt trust
  • If you push them too late, you miss conversion
  • If you don’t explain free vs paid clearly, nothing works


And most importantly, growth without guardrails will eat your core business.

That changed how we approached everything after.

Why This Actually Worked

Instead of shipping one off solutions, I turned what we learned into reusable systems. Two main ones:


Upgrade Value Interstitial
A context aware surface that shows up at key moments and explains the value of upgrading without breaking the flow


Promotional Upgrade Row
A content driven row inside discovery that surfaces premium content in a way that feels natural, not forced


Both were tied to user state, placement, and timing. Not just static components.

What I Took From This

The biggest shift was this:


We stopped redesigning surfaces every time the business changed.

Instead, we built a system that could adapt. When Philo introduced new bundles or changed packaging, we didn’t need to start over. The infrastructure handled it. Messaging updated. Entry points adjusted.


Experiments kept running. It gave the team speed without chaos.

Made with love in Orange County, CA.

Built in Figma Sites (Beta)

© Selected Works / Eric Sin

2018—2026

Consolidating Philo's Experience

System Architecture & Strategic Framework

Monetization was getting messy fast. Too many entry points, inconsistent upgrade flows, and experiments stepping on each other. I stopped thinking in screens and built a system that handled upgrade logic across the entire product. Now the team can test and ship without breaking the experience every time.

The Shift That Broke Everything

Philo used to be simple. One subscription. One path. Easy to explain. Then things changed. We introduced free entry points, bundles, and different ways to access the product. Good for the business, but it quietly broke the experience.


Upgrade paths got messy. Messaging got inconsistent. Users were bouncing between states without really understanding what they were getting or why they should pay. We didn’t just have a UX problem. We had a system problem.

What Was Actually Going Wrong

If you zoomed out, everything looked fine. But when you looked closer, it was fragmented. Upgrade flows depended on where you entered. Messaging changed depending on the surface. Free, trial, and paid states didn’t feel connected. And every new experiment risked stepping on something else.


Worst part, we started seeing cannibalization. Changes meant to drive growth were hurting our core subscription funnel. So the question wasn’t “how do we improve this screen.” It was “how do we stop this from breaking every time we touch it.”

Starting With a System, Not a Screen

I owned the design side of fixing this. Not just screens. The system behind it. That meant:


  • Thinking through every credential state across the lifecycle
  • Designing upgrade entry points across web, mobile, and TV
  • Working with Growth and PBS to align experiments with business goals
  • Running and learning from A B tests
  • Making sure whatever we built could scale without constant redesigns


This wasn’t a one feature problem. It was infrastructure.

Testing Our Assumptions (and Breaking Some Things)

Before designing anything new, I mapped the entire lifecycle. Free. Trial. Paid. Every state, every transition, every edge case. From there I defined:

  • Where upgrade triggers should exist
  • When users should see them
  • What context they should have before hitting them


This became the foundation for everything else. Instead of reacting to problems, we had a model we could build on.

Turning Learnings Into Product Infrastructure

We ran a lot of experiments. Some of them worked. Some of them didn’t. We tested removing the 10 foot landing page. We tested new upgrade entry points. We tested embedding upgrade education directly into the product instead of relying on external flows. What we learned pretty quickly:


  • If you push upgrades too early, you hurt trust
  • If you push them too late, you miss conversion
  • If you don’t explain free vs paid clearly, nothing works


And most importantly, growth without guardrails will eat your core business.

That changed how we approached everything after.

Why This Actually Worked

Instead of shipping one off solutions, I turned what we learned into reusable systems. Two main ones:


Upgrade Value Interstitial
A context aware surface that shows up at key moments and explains the value of upgrading without breaking the flow


Promotional Upgrade Row
A content driven row inside discovery that surfaces premium content in a way that feels natural, not forced


Both were tied to user state, placement, and timing. Not just static components.

What I Took From This

The biggest shift was this:


We stopped redesigning surfaces every time the business changed.

Instead, we built a system that could adapt. When Philo introduced new bundles or changed packaging, we didn’t need to start over. The infrastructure handled it. Messaging updated. Entry points adjusted.


Experiments kept running. It gave the team speed without chaos.

Made with love in Orange County, CA.

Built in Figma Sites (Beta)

© Selected Works / Eric Sin

2018—2026

Consolidating Philo's Experience

System Architecture & Strategic Framework

Monetization was getting messy fast. Too many entry points, inconsistent upgrade flows, and experiments stepping on each other. I stopped thinking in screens and built a system that handled upgrade logic across the entire product. Now the team can test and ship without breaking the experience every time.

The Shift That Broke Everything

Philo used to be simple. One subscription. One path. Easy to explain. Then things changed. We introduced free entry points, bundles, and different ways to access the product. Good for the business, but it quietly broke the experience.


Upgrade paths got messy. Messaging got inconsistent. Users were bouncing between states without really understanding what they were getting or why they should pay. We didn’t just have a UX problem. We had a system problem.

What Was Actually Going Wrong

If you zoomed out, everything looked fine. But when you looked closer, it was fragmented. Upgrade flows depended on where you entered. Messaging changed depending on the surface. Free, trial, and paid states didn’t feel connected. And every new experiment risked stepping on something else.


Worst part, we started seeing cannibalization. Changes meant to drive growth were hurting our core subscription funnel. So the question wasn’t “how do we improve this screen.” It was “how do we stop this from breaking every time we touch it.”

Starting With a System, Not a Screen

Before designing anything new, I mapped the entire lifecycle. Free. Trial. Paid. Every state, every transition, every edge case. From there I defined:

  • Where upgrade triggers should exist
  • When users should see them
  • What context they should have before hitting them


This became the foundation for everything else. Instead of reacting to problems, we had a model we could build on.

Testing Our Assumptions (and Breaking Some Things)

We ran a lot of experiments. Some of them worked. Some of them didn’t. We tested removing the 10 foot landing page. We tested new upgrade entry points. We tested embedding upgrade education directly into the product instead of relying on external flows. What we learned pretty quickly:


  • If you push upgrades too early, you hurt trust
  • If you push them too late, you miss conversion
  • If you don’t explain free vs paid clearly, nothing works


And most importantly, growth without guardrails will eat your core business.

That changed how we approached everything after.

Turning Learnings Into Product Infrastructure

Instead of shipping one off solutions, I turned what we learned into reusable systems. Two main ones:


Upgrade Value Interstitial
A context aware surface that shows up at key moments and explains the value of upgrading without breaking the flow


Promotional Upgrade Row
A content driven row inside discovery that surfaces premium content in a way that feels natural, not forced


Both were tied to user state, placement, and timing. Not just static components.

Why This Actually Worked

The biggest shift was this:


We stopped redesigning surfaces every time the business changed.

Instead, we built a system that could adapt. When Philo introduced new bundles or changed packaging, we didn’t need to start over. The infrastructure handled it. Messaging updated. Entry points adjusted.


Experiments kept running. It gave the team speed without chaos.

What I Took From This

This was the project where I stopped thinking in features.

And started thinking in systems.

A few things stuck with me:

If your growth strategy isn’t systemized, it will break under pressure
Context matters more than placement
Reusable infrastructure is more valuable than perfect UI

And honestly, most design problems at this level aren’t UI problems. They’re coordination problems between product, business, and engineering.t

Made with love in Orange County, CA.

Built in Figma Sites (Beta)

© Selected Works / Eric Sin

2018—2026