Designing and shipping our first paid B2C experience

We started with technical research to address specific requests from the business before properly shaping the solution. These are two of the most relevant ones, along with the answers from the team:

Q. Can socios have a 30-day trial without requiring a credit card upfront?

A. Not through the App Store, which forces users to enter their credit card and accept a paid subscription when enrolling into the trial. When the trial expires, we must redirect socios to a web-based service like Stripe.

Q. Can we create coupon codes through the stores? (this was a request from marketing to engage potential customers through social media and in-person events.)

A. It was possible to do this through the stores, but it was fairly complex to do it how the business needed it.

The answer to both questions was "yes, but it is not that easy." The first one, in particular, required us to take the users out of the app to pay on the web and then go back—a series of actions that were particularly difficult for our low-tech savvy profile to perform. We discussed and decided to keep the project short since B2C is not our primary business model.

The pitch

At MiSalud, we follow the Shape Up process for product development, which has proven to be both effective and lightweight. As part of this approach, I started by writing a pitch—a short document that outlines the problem (as described above), proposes a high-level solution, sets the appetite, defines the team, and flags potential rabbit holes or boundaries (the “no-gos”).

Rabbit holes and no-gos

In Shape Up, a no-go refers to functionality that’s intentionally left out of scope. A rabbit hole is a risky or overly complex area we choose to avoid to protect the timeline and stay within our appetite. For this project, here were a few we identified early on:

• We wouldn't support payments through the web, only through the stores
• Refunds would be handled manually
• Promo codes were not part of this first version
• If a user schedules a consultation and then their subscription expires, we would cancel the consultation manually in our system

Appetite and team

The appetite—the amount of time we’re willing to spend on a project—was set at six weeks by our Chief Product Officer. While we wanted to move quickly, the functionality was complex and required thorough QA. The team included two frontend engineers, one backend engineer, one QA engineer, and myself as the product designer.

Solution

I met with the Design Lead and two engineers to whiteboard the solution together. These are the scenarios we came up with:

‍
Scenario 1

A user creates an account and is automatically enrolled into a 30-day trial:

1. The user will see a non-intrusive banner at the top of the home screen, letting them know they are on the trial period
2. A paywall will be displayed when tapping on that banner
3. They will be able to choose a plan and pay through the stores
4. They will also see a section in the profile section indicating the status of the subscription: trial or active (one month, six months, or one year)
5. They could start the same process to pay for a subscription from the profile as well

Scenario 2

A user has an active trial that will expire in 5 days:

1. The banner will change to a reddish color to give a sense of urgency, along with a label that indicates the days left in the trial
2. After every consultation, the user will see a drawer inviting them to choose a plan

‍
Scenario 3

A user has a subscription already and wants to cancel:

1. They can go to the profile section, tap on the membership menu item, and see a list of steps to follow for canceling through the store (Android or iOS)

‍
Scenario 4

A user's subscription is about to renew automatically:

1. We will send an email five days before the renewal to let them know and remind them about the benefits of their current plan
2. One day before, we will send an SMS with the basic information about the renewal

Tracking behavior from day one

I defined the _events_ we will send to Mixpanel to measure the solution's effectiveness and observe our socios' behavior. These are some of the metrics I suggested to implement:

• Payment flow: started: triggered when the socio opens the paywall
  - triggered_from: a property that tracks where the event is triggered from (home screen, profile, or post-consultation)

• Payment flow: plan selected: triggered when the socio taps on one of the plans
  - membership_length: a property that tracks the plan they selected (one month, six months, or one year)
• Payment flow: payment successful: triggered after the socio pays through the store
• Payment flow: subscription canceled: when canceled from the stores
• Payment flow: subscription renewed: after automatic renewal
• Payment flow: subscription updated: when changed to another plan through the stores
• User traits: besides the events and their properties, we attached (or updated) properties to the user profile based on the status of their subscription:
  - membership_status: subscription active, trial active, trial expired, membership expired
  - membership_length: one month, six months, or one year
  - user_type: B2C or B2B

These metrics would allow me to create reports, funnels, and flows in Mixpanel to understand where users typically drop, from which touchpoint they subscribe the most, and which plans they choose.

I presented the pitch to the stakeholders, got a thumbs up, and kicked off the project.

‍
The project

‍
We kicked off the project during one meeting and then kept track of its progress in Notion. Even though we do Shape Up, we use Notion instead of Basecamp because we prefer to centralize the documentation for projects and non-related projects. A few months ago I was able to create a template with all the sections we needed (along with a great tool from the Zero Mile and we use it for every project since then.

‍

The developers could start coding from day one because the pitch and the whiteboard were clear and specific. They didn't need mocks to make things work. They could use non-styled components and basic layouts while I worked with the designer to finalize the user interface. QA engineers also had everything they needed to start writing test cases.

Throughout the project, we ran into a number of unexpected tasks and had to make a few trade-offs along the way. Testing took up a significant part of the six-week window, but we planned for that by validating each piece as it was completed—instead of waiting until the end. Thanks to that approach, we shipped on time without delays.

‍

We waited a couple of quarters to start measuring the real impact of our efforts. Over time, we saw a steady increase in B2C subscriptions and began to better understand the behavior of users who were most likely to convert.

Here’s what we found:

Conversion funnel

• 13% of users who created an account started the subscription flow
• 1% of those users completed a payment

User behavior

• 47% of paying users had attended at least two consults before subscribing

Preferences

• 85% of users chose the monthly plan over the other two options.
• 68% of subscriptions came from iOS devices

These numbers helped us confirm that early engagement drives conversions and that offering flexibility—rather than pushing long-term commitment—was key to unlocking growth.

This project helped us launch a solid foundation for our B2C offering—designed, built, and delivered quickly without losing sight of what mattered: giving users a clear, simple way to access care. While our focus remained on supporting B2B partners and their employees, this initiative gave us meaningful insights into how consumers interact with our product when they’re navigating it on their own.

It also surfaced clear opportunities for refinement—like improving conversion, testing pricing models, and adapting the trial experience—all grounded in real usage patterns and feedback. Those insights will continue to guide future iterations, even as we prioritize our core B2B audience.

‍