The cancellation rule owners wanted would have cost them more.

Role

Hired to add to the product, not redesign it.

Jundu came with two live apps and a roadmap from an earlier study. The brief was narrow: fit new features into the existing product.

My main piece was Clubinho, a membership that lets athletes join a venue instead of paying per booking, plus the payment flow and cancellation policy it needed. I owned it end to end, then handed it to the implementation team with components, guidelines and a reference prototype.

Context

A sand supplier, a certification seal and two apps.

Jundu supplies sand for sports courts. Venues built with it can become certified SuperQuadra Jundu partners, a network Jundu curates itself.

The athlete app listed venues and showed which slots looked free, but booking meant a WhatsApp message and paying at the court. The owner app handled setup, and its dashboard listed recent visitors. Both apps worked. Neither handled money.

The problem

How do you add a subscription to a product that has never taken a payment?

1. What does an owner configure when creating a plan?
2. How does an athlete compare plans and commit with confidence?
3. How are cards stored and recurring charges authorized?
4. What happens when a charge fails?
5. What happens when an athlete wants to leave early?
6. Who pays for a cancellation, the athlete or the venue?
7. What happens to availability when bookings become real transactions?
8. How does the owner see what the venue earns?

Adding Clubinho meant making the marketplace capable of a new business model.

Building on existing research

The research existed. I checked whether it still held.

I updated the competitive analysis instead of repeating it: who was still active, who had entered, and how memberships had evolved. For cancellations, I looked at the industry with the most experience in time-sensitive bookings: hospitality, specifically Airbnb and Booking.com, whose policies live inside the booking flow.

Two users

Athletes wanted flexibility. Owners wanted predictability.

1. 01Athletes

   Every athlete already paid for a club membership elsewhere, so nothing needed explaining. What decided it was how clear the value, the commitment and the way out were.

2. 02Venue owners

   Owners wanted predictable income but kept coming back to cancellations: tense refund talks at the counter, last minute gaps nobody paid for, and card fees paid twice on refunds. Their most common proposal was blunt: if an athlete leaves early, return only 30% of the remaining months.

That proposal shaped the most important decision of the project.

Real scope

One feature. Seven parts of the product.

Before any screen, I traced every flow Clubinho would touch: plans, recurring payment, booking, availability, cancellation, refunds and reporting. If athletes could pay in the app, so could single bookings. Paid bookings needed a history and a real calendar. Cancellations in the app needed a policy. Money in the platform meant the dashboard could finally show revenue.

Design

Owners needed to create a product. Athletes needed to buy one.

Owners create, edit and remove plans, each with a name, a tier and a price per billing frequency. Athletes compare plans and pay by card in the app. The recurring charge and the exit conditions are part of the offer, shown before payment, not left to the fine print.

Payment

Once money moves inside the product, everything around it has to be precise.

With Engineering, I defined what was needed to process payments, store cards and run recurring charges, which brings the product into PCI DSS and Brazil's data protection law, the LGPD. I designed every path: success, declined cards, incomplete payments, confirmations, renewals and the recovery routes between them.

The cancellation policy

The rule owners asked for would have cost them more.

Brazil's Consumer Protection Code protects the right to end a recurring contract and voids abusive clauses. Courts and consumer agencies like Procon generally accept an early termination fee of up to 10% of the remaining balance.

Keeping 70% would read as abusive, and push athletes to dispute the charge with their bank. Chargebacks bring extra fees for the merchant. The rule meant to protect revenue would have cost it. The policy that shipped moves the incentive to the moment of purchase:

1. Longer plans carry a real discount over the monthly price.
2. Leaving early cancels that discount: months already used are repriced at the monthly rate.
3. On top of that, a fee of at most 10% applies to the remaining balance.

Athletes keep a real benefit and a fair exit. Owners aren't left paying for cancellations. And nobody can take the annual discount and leave after a month.

Transparency

No one should stay subscribed by accident.

A recurring charge only earns trust if leaving is as easy as joining. Three rules ran through the whole experience: terms shown at the moment of subscribing, cancellation always visible with its conditions, and a notice by email and push before every renewal, early enough to cancel.

This was a deliberate tradeoff. Hidden terms and silent renewals raise subscriptions in the short run. Here they would have cost trust with athletes, work for owners and legal risk for Jundu.

From availability to real bookings

A court slot stopped being information and became a transaction.

With payments in place, single bookings moved into the app too: choose a venue and court, pick a free slot, review, pay, get a confirmation, and manage it later from a booking history athletes never had. Owners got a real calendar, built from their opening hours and updated as athletes book.

For single bookings, refunds follow a time-based model inspired by Airbnb's, reviewed with Jundu's Legal team: the earlier you cancel, the more you get back. Within the window, athletes can reschedule instead, which keeps them playing and keeps the money with the venue. Every cancellation screen shows the consequence in money before confirming.

Dashboard

Operational data became business data.

The owner dashboard used to list who had visited. With bookings and plans paid in the app, it shows what the venue earns: revenue, bookings and cancellations in the month, comparison with last year, and active Clubinho plans with their recurring income. None of it needed a separate analytics project. It came from completing the transaction model.

Tradeoffs

The decisions behind the design.

1. 01Protection through pricing, not penalties.

   A discount lost when leaving early plus a fee capped at 10% protects the same revenue as the 70% rule, stays within what Brazilian courts accept, and makes chargebacks far less likely.

2. 02Transparency over short-term conversion.

   Visible terms, a visible exit and a reminder before every renewal will lose some renewals a quieter design would keep. The ones that stay are honest, and Jundu stays out of consumer complaints.

3. 03Rescheduling before refunding.

   Offering a new slot before a refund keeps the athlete playing and the money with the venue, which a refund policy alone can't do.

4. 04Payments for single bookings too.

   Clubinho only needed recurring payments. Extending payments to single bookings widened the project, but gave both apps one transaction model and made the calendar and revenue dashboard possible.

Handover

Built to be measured after I left.

Everything in this case was implemented, and Clubinho launched on iOS and Android. Once the solution was stable enough to scale, I moved on and an implementation team carried it forward with the components, guidelines and reference prototype I delivered. Before leaving, I handed over the metrics to follow the launch:

1. Clubinho adoption per venue
2. Renewal and early cancellation rates
3. Reschedules as a share of booking cancellations
4. Share of bookings paid inside the app
5. Chargebacks and payment disputes
6. Recurring revenue per venue

I wasn't there to see the results, so this case reports none.

Impact

The feature changed more than the feature.

How the work was built

Methods, in order.