As a sole designer, launched first freemium feature for a C2C app "heyroom", driving revenue and increasing Daily Active Users by approx 15%
As a sole designer, launched first freemium feature for a C2C app "heyroom", driving revenue and increasing Daily Active Users by approx 15%
heyroom.app
heyroom.app
Overview
Overview
heyroom is an early-stage C2C startup with over 30,000 active users. It provides rooms and roommates to people in Germany by matching their vibes (similar to dating apps but for finding roommates).
heyroom is an early-stage C2C startup with over 30,000 active users. It provides rooms and roommates to people in Germany by matching their vibes (similar to dating apps but for finding roommates).
My Role
My Role
Sole Product Designer handling e2e design process
Sole Product Designer handling e2e design process
Team
Team
1 Product Designer (Me)
1 Founder/CEO
1 CTO
1 Front-end Developer
1 Back-end Developer
1 Product Designer (Me)
1 Founder/CEO
1 CTO
1 Front-end Developer
1 Back-end Developer
Timeline
Timeline
Oct-Dec’24
Oct-Dec’24
Problem Statement
Problem Statement
How might we introduce first paid feature within 8 weeks for searchers (who are looking for rooms on the app) that doesn’t lead to drop-offs & increase DAU, considering limited number of rooms on the app and create a scalable revenue stream for heyroom?
How might we introduce first paid feature within 8 weeks for searchers (who are looking for rooms on the app) that doesn’t lead to drop-offs & increase DAU, considering limited number of rooms on the app and create a scalable revenue stream for heyroom?
Impact
Impact
On January 17th, 2025, heyroom launched its first freemium feature aimed at generating revenue without increasing user drop-off.
On January 17th, 2025, heyroom launched its first freemium feature aimed at generating revenue without increasing user drop-off.
Daily active users
Daily active users
10–15% rise in DAU in the first week
10–15% rise in DAU in the first week
Conversion
Conversion
12 payments in the first week of launch
12 payments in the first week of launch
Users
Users
heyroom has two types of users:
heyroom has two types of users:
Searchers
Searchers
Looking for rooms
Looking for rooms
Offerers
Offerers
Listing rooms on the app and looking for roommates
Listing rooms on the app and looking for roommates
Business Goal
Business Goal
Founder wanted to launch the first paid feature for Searchers. Until then, the app had been completely free, so this was a big shift in how searchers would experience the product.
Founder wanted to launch the first paid feature for Searchers. Until then, the app had been completely free, so this was a big shift in how searchers would experience the product.
Reason
Reason
The app already had some UX issues, and room supply was limited, so I initially asked:
Should we fix existing problems first before monetization?
But the founder clarified that they had to show revenue otential before the next investor meeting to get funding.
The app already had some UX issues, and room supply was limited, so I initially asked:
Should we fix existing problems first before monetization?
But the founder clarified that they had to show revenue otential before the next investor meeting to get funding.
Challenge
Challenge
Since heyroom was completely free, my main challenge was introducing friction, that is, a paid feature into a critical flow without breaking users’ trust or usage.
Since heyroom was completely free, my main challenge was introducing friction, that is, a paid feature into a critical flow without breaking users’ trust or usage.
Problem structuring with the founder
Bringing clarity - So I sat down with the founder and further discussed on structuring the problem properly. While revenue was the obvious business goal, I suggested that it shouldn’t be the only KPI, because with limited room supply, searchers can only apply to so many rooms anyway. So together, we reframed the KPI's as:
Daily Active Users; Revenue; Drop-off
Hypothetical Solution
Problem structuring with the founderr
Bringing clarity - So I sat down with the founder and further discussed on structuring the problem properly. While revenue was the obvious business goal, I suggested that it shouldn’t be the only KPI, because with limited room supply, searchers can only apply to so many rooms anyway. So together, we reframed the KPI's as:
Daily Active Users; Revenue; Drop-off
Hypothetical Solution
To achieve this goal, we brainstormed on several ways on defining the paid feature.
One key insight was that because heyroom had always been 100% free, introducing a sudden hard paywall could have led to break of trust and increase in churn, especially given the limited number of rooms available. This would undermine the long-term health of the product.
Based on that insight, we researched & decided to test a freemium model instead of a hard paywall. For example, users could apply to a few rooms per day for free, and can purchase our paid option to apply to more rooms if needed.
This allowed users to continue using the core flow, experience value first, and choose to pay only when it felt justified.
To achieve this goal, we brainstormed on several ways on defining the paid feature.
One key insight was that because heyroom had always been 100% free, introducing a sudden hard paywall could have led to break of trust and increase in churn, especially given the limited number of rooms available. This would undermine the long-term health of the product.
Based on that insight, we researched & decided to test a freemium model instead of a hard paywall. For example, users could apply to a few rooms per day for free, and can purchase our paid option to apply to more rooms if needed.
This allowed users to continue using the core flow, experience value first, and choose to pay only when it felt justified.
Constraints
Constraints
Once the direction was clear, I mapped out the constraints.
We had only one developer working in a different time zone, I was handling the entire design process on my own, and we had a strict deadline of 8 weeks to ship.
Understanding these constraints helped me focus on designing only what truly mattered, keeping the work simple and easy for the developer to build.
Once the direction was clear, I mapped out the constraints.
We had only one developer working in a different time zone, I was handling the entire design process on my own, and we had a strict deadline of 8 weeks to ship.
Understanding these constraints helped me focus on designing only what truly mattered, keeping the work simple and easy for the developer to build.
Brainstorming with cross-functional teams to set priorities & understanding interdependencies
Brainstorming with cross-functional teams to set priorities & understanding interdependencies
Before diving deeper into UI, I looked at how we were working internally.
Before diving deeper into UI, I looked at how we were working internally.
Bottleneck - One major bottleneck was that there was no proper design setup in place. Developers were relying on screenshots shared by the founder, which led to misinterpretations, delays, and inconsistent UI.
Bottleneck - One major bottleneck was that there was no proper design setup in place. Developers were relying on screenshots shared by the founder, which led to misinterpretations, delays, and inconsistent UI.
Solution - To fix this, I introduced Figma as a single source of truth and used Loom walkthroughs to explain flows asynchronously. This significantly reduced back-and-forth and helped the team move faster despite the time-zone gap.
Solution - To fix this, I introduced Figma as a single source of truth and used Loom walkthroughs to explain flows asynchronously. This significantly reduced back-and-forth and helped the team move faster despite the time-zone gap.
Gathering insights from observing dating apps
Gathering insights from observing dating apps
With the process in better shape, I looked at how similar products handled monetization. Dating apps were the closest comparison, and
With the process in better shape, I looked at how similar products handled monetization. Dating apps were the closest comparison, and
One pattern that stood out was the use of timers and limits to clearly show:
How much free usage is left
When the next free action becomes available
This visual clarity could have helped users understand limits without feeling lost.
One pattern that stood out was the use of timers and limits to clearly show:
How much free usage is left
When the next free action becomes available
This visual clarity could have helped users understand limits without feeling lost.
Created Mid-Fidelity Wireframes
Created Mid-Fidelity Wireframes
Given the tight timeline, I focused on designing only what was essential :
Used existing components
Created mid-fidelity prototypes of freemium card, modals explaining room limits, & pricing screen
Validated feasibility with the developer early to avoid surprises later
Given the tight timeline, I focused on designing only what was essential :
Used existing components
Created mid-fidelity prototypes of freemium card, modals explaining room limits, & pricing screen
Validated feasibility with the developer early to avoid surprises later
Conducted usability testing
Conducted usability testing
To validate the solution, I tested the final prototype with
To validate the solution, I tested the final prototype with
Users - 5
Location - Berlin
Currently live with roommates or are seeking rooms
Users - 5
Location - Berlin
Currently live with roommates or are seeking rooms
This led to below user insights -
This led to below user insights -
Gave the designs to the developers for testing and we found an issue
Implemented required changes after user insights but during development, we hit an unexpected setback.
Once the UI was translated into German, long German words broke the layouts.
To solve it, within 3–4 days:
Consulted senior designers from my network
Studied multilingual UI best practices
And made the final changes considering German localization
Gave the designs to the developers for testing and we found an issue
Implemented required changes after user insights but during development, we hit an unexpected setback.
Once the UI was translated into German, long German words broke the layouts.
To solve it, within 3–4 days:
Consulted senior designers from my network
Studied multilingual UI best practices
And made the final changes considering German localization
Final Design Output
Final Design Output
Redesigned the layout for better language fit & usability
Redesigned the layout for better language fit & usability
Finally I updated the final designs to work well in both English & German versions.
Finally I updated the final designs to work well in both English & German versions.
Redesigned the layout for Payment screen
Redesigned the layout for Payment screen
Mapped 3 user flows
Mapped 3 user flows
To guide users at different stages of their daily limit, I designed clear flows to inform, encourage, and upsell without disrupting their experience.
To guide users at different stages of their daily limit, I designed clear flows to inform, encourage, and upsell without disrupting their experience.
Handoff and Prototype
Handoff and Prototype
I used these tools to collaborate, design and handoff
I used these tools to collaborate, design and handoff
Challenges & Learnings
Challenges & Learnings
